3 ms·

Yeah. 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 blan

Yeah. 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 ago
That's because "REST" is used as a buzzword for "Plain Old HTTP" much more commonly than to mean "REpresentational State Transfer".
zzzeek 13y ago
I 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 ago
  I'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 ago
True 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 ago
  The 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.

Yeah. 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 ago

That's because "REST" is used as a buzzword for "Plain Old HTTP" much more commonly than to mean "REpresentational State Transfer".

zzzeek 13y ago

I 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 ago
I'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 ago

True 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 ago
The 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.