3 ms·
There are several reasons. 1. The general pattern of an aggregation service only covering the lowest common denominator features among what it aggregates. 2.
by tedmiston 11y ago
There are several reasons.
1. The general pattern of an aggregation service only covering the lowest common denominator features among what it aggregates.
2. I'm not sure of Kayak's terms specifically but accessing via third party aggregator API vs. direct API can affect who gets credit for the referral (i.e., $$$).
3. At the aggregator level, _someone_ has to write the glue code for all of the services. See IFTTT for an example of this. This is a good foreshadow of the problems here by analogy to IFTTT [1].
4. "Just slap together an SPA that calls the same aggregation service, and prefill it with the recognized query." Who's going to build the SPA? For each service vertical? For each company?
[1]: https://blog.pinboard.in/2016/03/my_heroic_and_lazy_stand_against_ifttt/ https://blog.pinboard.in/2016/03/my_heroic_and_lazy_stand_ag...
- losteric 11y ago1. That is just convention, services are free to filter on features that are present on a small subset of the data. 2. I don't know how Kayak specifically works, they're just a general example of a customer-facing website that also vends an API that could be integrated with Voice UX. 3 / 4. Everyone has a different approach here and I'm not sure how Viv's would work... but Alexa's ownership model is app-based. 3rd parties build services that process the user's command however they want. They build the backend service, the Alexa voice integration endpoint, and (optionally) a companion website. Amazon owns the marketplace and physical interface. In this model, Uber owns the Uber integration, Lyft owns the Lyft integration, and whoever manages to search both Uber and Lyft would own that meta-service integration.