Scraping and aggregating airline info is not really comparable. Airline data is based on predetermined schedules and is relatively static.

Ride hailing is extremely fluid. Must be real-time. Must be able to provide GPS coordinates of the user to the service in question.

I don't think you'll see an aggregation app until there is some ride hailing standard that is adopted by the various providers.

Google Maps is already starting down this road a bit (admittedly only with the big companies). That's the likeliest path in terms of companies that have the leverage as well as the existing technology to make this happen.

You don't need a standard, the taxi companies just all need some API. Apps like "Transit App" will just integrate them all.

> You don't need a standard, the taxi companies just all need some API

But what does that API look like? What are the MVP operations required to make a successful ride hailing API? Will that API provide realtime location info of the driver, or allow payment, or <insert myriad of questions here>.

Without a standard, the Taxi API landscape will be a mess.

> Apps like "Transit App" will just integrate them all

This is a pretty major oversimplifications of this issue. Sure, this is technically possible, but it sounds like a horrible solution.

Bringing in the considerations about the actual API design, this also means that user experience may vary wildly depending on which service they're interacting with.

Can != should. If aggregating many systems is the future, we should push for a technical solution that doesn't suck.

You're overcomplicating the issue - a lot. The important thing is that the ride sharing systems provide APIs that show the time and the price, to allow users to compare. The next step is that the service providers and apps can work together on payment, which is really the complicated part. Following the booked cars in real time is simple in comparison.

Not having some API standard is usually how it's done with many services nowadays, and the market/comparison apps have to integrate multiple APIs. Big deal.

Guess we just have to agree to disagree. API design matters. A lot. "As long as they provide some API" doesn't really cut it if you want a system that functions well. Having spent close to 10 years of my career gluing systems together through APIs, I've encountered too many "Oh we have an API!" vendors only to find out how horrible that API is. The consumer facing product is often a direct reflection of the underlying APIs powering it. If you have many APIs powering it, the app will take on all of the negatives of the sum of those APIs. Good app design can help smooth over the rough edges, but that only goes so far.

Again, I should reiterate: I'm not arguing that it can't be done or that it's not possible. I'm arguing that the result will be subpar. Let's remember that the parent discussion is about the creation of a system that rivals the Uber/Lyft experience. If you want to do that, someone (probably someone big like Google as suggested in another comment) is going to have to influence the design of these APIs so the end user experience is a consistent/good one.

So? Then there will be a standard of sorts.

Perhaps so. The point was: scraping/aggregating/etc for car services is not comparable with what sites like Kayak do for the airline industry.

There very well may be one ride hailing app to rule them all, but implementing it will be an entirely different beast.

That's exactly what I predict the market will move to