4 ms·

It's complicated, difficult to understand, requires large tools (expensive ide's) to be productive with, different vendors have different interpretations of SOA

It's complicated, difficult to understand, requires large tools (expensive ide's) to be productive with, different vendors have different interpretations of SOAP anyways. Basically, it's a bunch of extra work and requires more documentation due to the complexity of it's implementations. Also, SOAP libraries (e.g. Soap4r) are problematic (doesn't talk to Micro$soft's version of SOAP properly). REST is over HTTP. Just about all programming environments have a HTTP library.

viraptor 16y ago
Just playing a devil's advocate here a little bit, but soap doesn't really require that much. For example for .net, you just run wsdl on some url and it generates the interface code for you. Also the complexity is needed when your size goes up. Even verifying that the requests make sense is easier with schemas. Right now there is some project for json-schema going on, but it's not crazy popular yet. SOAP can be self-documenting too with its own structure mappings, type restrictions, etc. etc. Don't you think it's only delaying the fact you'll have to reimplement the same stuff at some point yourself (since json based rest simply doesn't provide them out of the box)? (yeah - I know rest is protocol independent, so you can have xml and schemas too, but majority of "rest" services just throw some json and hope it sticks ;) - too bad if it changes between versions)
- binspace 16y ago
  First of all, the fact that you need such a code generator for the interface is a smell, not a good thing. To consume a REST service, you just need an HTTP client, possibly some authentication hashing, a url, and parameters and a json parser. You then get a hash. The Web services I've used tend not to be super complicated. A handful of api calls tend to be used. There's also versioning, which is handled well with a good url structure. Also, the schema problem is more of a JSON vs XML issue. I personally use JSON because it's simpler for flatter data graphs. I also use JSON schema btw. XML does have the advantage of xpath (or css selectors) too. But even in the REST + XML case, the XML is simpler than the XML + SOAP case. Which brings up Content-Type. Rest can serve pretty much any content type in a way that's readable by almost any web-enabled client. Not so with SOAP. You need to have more software. Basically, I can add these features on an as needed basis. REST is easier to work with right now and I probably will not need all of the features of SOAP. That's the gist of why it's less popular now.
- Roboprog 16y ago
  And how many internet startups are using VisualStudio.NET? (non-0, to be sure, but they are the outliers) And pay attention to the cross-stack arguments, to say nothing of the cross version differences. You remind me of this guy on stackoverflow: http://stackoverflow.com/users/76337/john-saunders http://stackoverflow.com/users/76337/john-saunders -- M.S. kool-aid, yummie! I am still waiting for any feedback (not from John, just in general) on this question: http://stackoverflow.com/questions/2194316/good-book-for-writing-java-clients-for-sundry-web-services http://stackoverflow.com/questions/2194316/good-book-for-wri... I guess anybody who know how to do these would be out pillaging and plundering corporate "america", not writing books :-)
masklinn 16y ago
> REST is over HTTP. SOAP is a message protocol, it's perfectly possible (and indeed pretty common) to run SOAP over HTTP. In fact that's probably the most common SOAP transport.
- binspace 16y ago
  True, it's over HTTP and that's pretty much it. No abstraction layer (with software) that duplicates many features that HTTP already provides.
andrewf 16y ago
Also, SOAP libraries (e.g. Soap4r) are problematic (doesn't talk to Micro$soft's version of SOAP properly). I feel this point never quite lands home with people who've never tried to use SOAP across ecosystems (ie not .NET-.NET, Glassfish-Glassfish, etc). Put in plain terms: It just doesn't fucking work.
- reinhardt 16y ago
  I've never had to use SOAP so I may be off here but isn't the above "just" a matter of bad implementations and not necessarily SOAP itself ? It sounds like blaming HTML/CSS/Javascript because there are crappy browsers that don't follow the standards.
  - andrewf 16y ago
    I think a lot of it comes down to SOAP, and related standards, being ambiguous and changing enough over time that even if you follow the standards, it isn't necessarily clear what you can and should do. Take a look at WS-I, the standard which tells you just how you should implement all of the standards that came before it, if you actually want to talk to other implementations: http://ws-i.org/profiles/BasicProfile-1.2-WGD.html http://ws-i.org/profiles/BasicProfile-1.2-WGD.html I first looked at SOAP in 2007. It made more sense to me after I read this: http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/ http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-...
  - deleted 16y ago
    [deleted]

viraptor 16y ago

Just playing a devil's advocate here a little bit, but soap doesn't really require that much. For example for .net, you just run wsdl on some url and it generates the interface code for you. Also the complexity is needed when your size goes up. Even verifying that the requests make sense is easier with schemas. Right now there is some project for json-schema going on, but it's not crazy popular yet. SOAP can be self-documenting too with its own structure mappings, type restrictions, etc. etc. Don't you think it's only delaying the fact you'll have to reimplement the same stuff at some point yourself (since json based rest simply doesn't provide them out of the box)? (yeah - I know rest is protocol independent, so you can have xml and schemas too, but majority of "rest" services just throw some json and hope it sticks ;) - too bad if it changes between versions)

binspace 16y ago
First of all, the fact that you need such a code generator for the interface is a smell, not a good thing. To consume a REST service, you just need an HTTP client, possibly some authentication hashing, a url, and parameters and a json parser. You then get a hash. The Web services I've used tend not to be super complicated. A handful of api calls tend to be used. There's also versioning, which is handled well with a good url structure. Also, the schema problem is more of a JSON vs XML issue. I personally use JSON because it's simpler for flatter data graphs. I also use JSON schema btw. XML does have the advantage of xpath (or css selectors) too. But even in the REST + XML case, the XML is simpler than the XML + SOAP case. Which brings up Content-Type. Rest can serve pretty much any content type in a way that's readable by almost any web-enabled client. Not so with SOAP. You need to have more software. Basically, I can add these features on an as needed basis. REST is easier to work with right now and I probably will not need all of the features of SOAP. That's the gist of why it's less popular now.
Roboprog 16y ago
And how many internet startups are using VisualStudio.NET? (non-0, to be sure, but they are the outliers) And pay attention to the cross-stack arguments, to say nothing of the cross version differences. You remind me of this guy on stackoverflow: http://stackoverflow.com/users/76337/john-saunders http://stackoverflow.com/users/76337/john-saunders -- M.S. kool-aid, yummie! I am still waiting for any feedback (not from John, just in general) on this question: http://stackoverflow.com/questions/2194316/good-book-for-writing-java-clients-for-sundry-web-services http://stackoverflow.com/questions/2194316/good-book-for-wri... I guess anybody who know how to do these would be out pillaging and plundering corporate "america", not writing books :-)

masklinn 16y ago

> REST is over HTTP. SOAP is a message protocol, it's perfectly possible (and indeed pretty common) to run SOAP over HTTP. In fact that's probably the most common SOAP transport.

binspace 16y ago
True, it's over HTTP and that's pretty much it. No abstraction layer (with software) that duplicates many features that HTTP already provides.

andrewf 16y ago

Also, SOAP libraries (e.g. Soap4r) are problematic (doesn't talk to Micro$soft's version of SOAP properly). I feel this point never quite lands home with people who've never tried to use SOAP across ecosystems (ie not .NET-.NET, Glassfish-Glassfish, etc). Put in plain terms: It just doesn't fucking work.

reinhardt 16y ago
I've never had to use SOAP so I may be off here but isn't the above "just" a matter of bad implementations and not necessarily SOAP itself ? It sounds like blaming HTML/CSS/Javascript because there are crappy browsers that don't follow the standards.
- andrewf 16y ago
  I think a lot of it comes down to SOAP, and related standards, being ambiguous and changing enough over time that even if you follow the standards, it isn't necessarily clear what you can and should do. Take a look at WS-I, the standard which tells you just how you should implement all of the standards that came before it, if you actually want to talk to other implementations: http://ws-i.org/profiles/BasicProfile-1.2-WGD.html http://ws-i.org/profiles/BasicProfile-1.2-WGD.html I first looked at SOAP in 2007. It made more sense to me after I read this: http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/ http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-...
- deleted 16y ago
  [deleted]