| A few things off the top of my head which are different across many RESTful APIs which prevent a unified client from being possible: - Referring to other data paths in the API in a standard format - Authentication. Shy of OAuth, it is totally different on each API. Most APIs avoid OAuth because its a PITA - Partial PUTs vs PATCH vs sub-resources All sorts of minor things are different across rest APIs, and that results in client libraries needing to be widely different. We are in need of a standardized API format which we can build compatible server & client libraries against. Something like SOAP for the JSON era. There are a few out there, but none have really gone anywhere. Are any of these extended-REST wrappers in production by any big companies? I'd love to be corrected. If not, maybe a high-profile company with a really nice API design could publish a standard on their API structure and refactor out their transport code to provide us with these libraries. If successful, they could be known for introducing a widely-used transport layer for the web industry. |
I don't get what you mean about data paths, though. Even if you had a hypothetical good REST client you'd still want a single point to do the URL string assembly to save typing and do some validation but this doesn't really require a whole different client.