[zzzeek]

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]

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.

[zzzeek]

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]

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.

[masklinn]

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

[alephnil]

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]

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-sta...

Also, I have never read anything implying POST requests are incompatible with REST.