6 ms·

The headline makes me think of NoSQL. The NoSQL (poor nomenclature) movement came about because of limitations with decades-old SQL. I don't think such problems

The headline makes me think of NoSQL. The NoSQL (poor nomenclature) movement came about because of limitations with decades-old SQL. I don't think such problems exist with REST, which is still fairly young. More importantly, REST created a relatively clean and clear API that almost anyone can understand for any service. Sure, it does vary, as it is not "standard", and every site has their own resources and paths, but the learning curve to a new API is dramatically lower.

MichaelGG 12y ago
What are some popular APIs that are truly REST? AWS isn't. Twilio isn't (extensions to indicate formatting (and the URLs are built on the client, instead of using hypermedia)). They seem to be doing just fine. And I still cannot see, for instance, how having POST /deleteAccount is so much less understandable or usable than DELETE <URL discovered through previous use of API>. As far as ease of use I certainly don't find it any easier to write clients that need to put parameters in the URL, headers, and in the body. And I've still gotta look at the documentation and most likely write a small client wrapper in most cases. Elasticsearch comes to mind, and actually, REST has only hurt my use of it, because simple typos that would cause errors otherwise now have meaning. Eg DELETE /index/type/id when id is empty deletes a whole type. Whereas with RPCish, I'd be calling a "deleteDocument" method so no id just means failure. Also, it's lots of fun when your document id doesn't encode well into the URL, like containing / or must-encode chars. So again, what's the benefit I'm gaining here? HTTP is fantastic cause it gives apps an easy client server wrapper for making TCP requests, along with some usable spots for request info and metadata. And as a bonus, GET vs POST lets us indicate a call might be read-only. Cramming APIs into some guys thesis on how HTTP should be used seems as weird as people that enjoy needlessly applying OO patterns to code.

MichaelGG 12y ago

What are some popular APIs that are truly REST? AWS isn't. Twilio isn't (extensions to indicate formatting (and the URLs are built on the client, instead of using hypermedia)). They seem to be doing just fine. And I still cannot see, for instance, how having POST /deleteAccount is so much less understandable or usable than DELETE <URL discovered through previous use of API>. As far as ease of use I certainly don't find it any easier to write clients that need to put parameters in the URL, headers, and in the body. And I've still gotta look at the documentation and most likely write a small client wrapper in most cases. Elasticsearch comes to mind, and actually, REST has only hurt my use of it, because simple typos that would cause errors otherwise now have meaning. Eg DELETE /index/type/id when id is empty deletes a whole type. Whereas with RPCish, I'd be calling a "deleteDocument" method so no id just means failure. Also, it's lots of fun when your document id doesn't encode well into the URL, like containing / or must-encode chars. So again, what's the benefit I'm gaining here? HTTP is fantastic cause it gives apps an easy client server wrapper for making TCP requests, along with some usable spots for request info and metadata. And as a bonus, GET vs POST lets us indicate a call might be read-only. Cramming APIs into some guys thesis on how HTTP should be used seems as weird as people that enjoy needlessly applying OO patterns to code.