> The Web is the platform. I am not sure to get exactly what you mean with that. But I was thinking about APIs recently and I will explain how I think it shoul

> The Web is the platform. I am not sure to get exactly what you mean with that. But I was thinking about APIs recently and I will explain how I think it should be done in the best of the worlds, it may have some relation with this assertion. First a note: I don't mean APIs can be like what I describe, nor that businesses should do like that, nor that it is easy or has no problems. It is just a point drawn in the plane for better distance measures. When I point my browser to http://someurlfoo.bar/user/A http://someurlfoo.bar/user/A, the server knows I am using a browser, knows who I am, and answers with a mix of HTML, javascript and other resources. Now if you check any API available you almost always have an equivalent GET http://api.someurlfoo.bar/user/A http://api.someurlfoo.bar/user/A, and the server will answer with some XML or JSON blob containing the information required (and often more). Setting authorization, optimization and bandwith issues aside for 5mn, one could just wonder why the ### those two interfaces are different. Why not read the ACCEPT header and answer with JSON, XML or HTML accordingly, serving apps, direct users and other client through the same dumbwaiter? Why not having just one interface? Benefits would be interesting: - user A would be able to present itself ("A, the name's A") in different languages: html, xml, json, whatever. - the information about a given topic should have the same content in every languages. Just take the data from the store and filter it through a jsonizer, an xmlizer or a htmlizer. - API client code would not have to read awful API docs that are obviously written by robots for robots: they would just change point their browser to the data they want, change the accept header to json and get their answer. It seems to me that, APIs having historically grown after normal web pages, they have been conceived as a separate service, but they are just the same core thing. Now let's go with possible objections: - Authorization should be handled the same way, but it is possible that the server would need to ensure that you are coming from which mobile app, or web app. It is easy to do with a double authentication: the app authenticate itself and passes along end user authentication token. This way the server knows who it is speaking to, through which intermediaries. - Bandwith: An important use for APIs nowadays, from the server's point of view, is the ability to avoid being flooded by bogus requests. An API key comes with limitations on the maximum amount of requests per day or the like. If both the end user and the client app authenticate themselves, then there should be no difficulty in giving priority to some clients over others (usually the direct browser access is preferred). - Optimization: This is maybe a bigger issue. From the APIs I have seen they seem carefully crafted to reduce the number of roundtrips required. For instance, a GET request for user/A might answer with A's name, number of followers, list of recent followers, same with followings, A's recent posts, creation date, last dog-walking time and culinary preferences. All of this makes no sense if all you need is A's full name. I think this optimization issue should be solved differently, even if we were to keep the current isolated status of APIs, but this if for another post. Edit: s/hatch/dumbwaiter/