This is a lot easier than the Charles MITM proxy I used to intercept the Uber iPhone API calls to determine mine. I feel kind of silly now that I didnt bother checking the web API.
I also made a web scraper to get my uber trip details (incl. route driven), save it to JSON and map the trips all at once. http://i.imgur.com/Q1W59rD.jpg. Here's a quick dump of the code https://github.com/joshhunt/uber. It's pretty rough and it makes a lot of assumptions (e.g. metric system and AUD). I never really plan on looking at it again, so your milage may vary.
I also found their API structure to be quite unusual: They make a call to something like `api.uber.com/` with POST data of something like
and you'll recieve a response back of something like
{
responseData: {
username: 'madeofpalk'
...rest of requested data...
},
vehicles: [
...list of all vehicles and their locations...
]
...other data that wasnt explicitly requested but comes through with every request...
}
I had never seen this pattern before, and thought it was quite unusual (especially for a 'new hip startup' that uses Python and Node.js). Anyone care to comment on why they may have choosen something like this?
This pattern is standard within SOA (Service Oriented Architecture).
You have two classes of services:
1. Technical Services
2. Business Services
The technical services may be REST, SOAP, etc. These deal with the nuts and bolts of: update this one thing, fetch a load of these things (where they are the same thing).
The business services are usually some flavour of RPC JSON or XML, and only occasionally are REST (think of a resource that is actually a composite of other resources, it's usually a business service).
The business service wraps the underlying technical service with the orchestration of which granular services to call, and returns something useful to the user (the client, in this case an app which is also made by the company).
What you quoted was the result of a business service, but you can imagine that behind that are services that individually fetch vehicles, user info, etc. The business service is just wrapping it and doing a useful thing for the user by returning the composite.
It should be noted, there's an idea of a "service catalog". Some people think this is wholly comprised of the business services, but actually it's the superset of both business and technical services. You might have 2 catalogs, one external and one internal... but both are made up of a mix of business and technical services. The goal is simple: Help users to get shit done. In the scenario given, "get shit done" means "perform multiple calls, and because it's mobile and calls are expensive return everything in one call".
Ah awesome thanks! Didn't cross my mind to link to the commit's line number. Still, have to agree with some commenters about having the link go to it by default.
Here's a quick dump of the code https://github.com/joshhunt/uber. It's pretty rough and it makes a lot of assumptions (e.g. metric system and AUD). I never really plan on looking at it again, so your milage may vary.
doesn't seem that strange to me. in the old SOAP days it was easier to run everything through a set of filters and just have what server code specified by a field.
in this case it is pretty clear they sped up requests by returning some generic data every request needed to update the app all at once as well. that's a pretty common requirement. netflix even allows client code to upload server code to pack responses into the least number
What I thought was strange is that we're not in the 'old SOAP days' any more.
I get what they wanted to do - speed things up by including common data in every request, and avoid state in apps. What I found strange was the way they solved it, esp. given they're (apparently) using Python and Node.js - writing a middleware to insert the common data would be far easier than implementing their own routing layer or whatever they've done.
Of course I'm making a lot of assumptions about what kind of stack exactly they're using (assuming they're using a web framework that we've heard of)
I did a similar hack in an app I wrote where I basically always wanted/needed a fresh copy of a user's account data. Literally halved the number of API calls necessary in early versions of the app. Now the gain is maybe 30% but the code is a lot cleaner regardless.
If, as another commenter mentioned, they want every request to update all the data in an app, this is quite an elegant pattern.
They don't have to modify any of their restful APIs to fetch or serialize more data than intended. Instead, the / endpoint might act as a wrapper, which does three things:
1. gets the entire app state
2. makes an internal API call of its own (proxies the one from the request)
I also made a web scraper to get my uber trip details (incl. route driven), save it to JSON and map the trips all at once. http://i.imgur.com/Q1W59rD.jpg. Here's a quick dump of the code https://github.com/joshhunt/uber. It's pretty rough and it makes a lot of assumptions (e.g. metric system and AUD). I never really plan on looking at it again, so your milage may vary.
I also found their API structure to be quite unusual: They make a call to something like `api.uber.com/` with POST data of something like
and you'll recieve a response back of something like I had never seen this pattern before, and thought it was quite unusual (especially for a 'new hip startup' that uses Python and Node.js). Anyone care to comment on why they may have choosen something like this?