4 ms·
REST is not losing its flair, this article's four points focus on things that have mostly nothing to do with the huge bread and butter of web services, which is
by zzzeek 13y ago
REST is not losing its flair, this article's four points focus on things that have mostly nothing to do with the huge bread and butter of web services, which is getting businesses to talk to each other and share data between entirely unrelated applications. #1 does not apply because these are simple data sharing services and async has nothing to do with it; #2 does not apply because these services are not internal; #3 does not apply because the other business you're talking to, RPC what? SDK-what? can I just send you my customer data in an XML file? #4 does not apply because see #3.
Then again, most "REST" as practiced for intra-business data is not really "REST" as far as purists would be concerned; while we at least do things like use HTTP error codes instead of an HTML page with "error" on it under a 200, I'd be laughed out of the conference room if I suggested our clients use a PUT instead of a POST. But who cares, as long as it's not SOAP.
- sopooneo 13y agoYeah. I've found a weird dichotomy in the general push to use "REST" for web APIs, but then certain aspects (true statelessness, for instance) are met with blank stares.
- masklinn 13y agoThat's because "REST" is used as a buzzword for "Plain Old HTTP" much more commonly than to mean "REpresentational State Transfer".
- zzzeek 13y agoI get just as many blank stares when I'm presented with a client that is using SOAP (btw, I'd say 100% of SOAP shops are .NET shops at this point), but their SOAP message consists of a single-element datastructure, the single element containing an XML document which is the actual payload, and I try to say, "that's not really SOAP..."
- tracker1 13y agoI'll give this to .Net though, at least their wsdl files are complete enough to generate a .Net client from.. that's about all I will give it in that regard... I can't stand SOAP, it's too cumbersome, and even more verbose in transport. Several times, in the past couple years, I've actually written internal translation services in node.js against public soap endpoints that I can more easily consume (usually in C#/.Net) Also, I've seen a lot of SOAP written in Java as well... Though the couple of PHP "SOAP" services I've had to consume have been the worst by far.
- alephnil 13y agoTrue statelessness? Even if you disregard POST as "not true REST", the PUT and DELETE methods involve changing state. REST is an acronym for "representational STATE transfer", and is all about dealing with state in an simple and transparent way, not about avoiding it.
- sopooneo 13y agoThe server can have state, but there should be no communication about the client state. This is most tricky regarding logged-in/out session state usually communicated with cookies. http://ruben.verborgh.org/blog/2012/08/24/rest-wheres-my-state/ http://ruben.verborgh.org/blog/2012/08/24/rest-wheres-my-sta... Also, I have never read anything implying POST requests are incompatible with REST.