Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SOAP: The 'S' stands for simple (not really)

harmful.cat-v.org

Post reply on HN
Print view View original

31–40 of 92 posts

Re: SOAP: The 'S' stands for simple (not really)

#31

Post by pornel »

ahupp wrote: post #27

At one time SOAP wasn't too bad, until it tried to solve a lot of complicated problems (via WS-*), and in the process made the simple problems complex. Contrast this with HTTP which is being used for ever-more complex problems yet is really no more complicated in the simple case than it was in 2000. This seems like an important principle in protocol design.

Indeed. "RESTful" is basically a name for using HTTP well, and such APIs are usable for anything from bash script to Big Vendor Library™.

Re: SOAP: The 'S' stands for simple (not really)

#33

Post by wiredfool »

bediger wrote: post #19

Why did SOAP win, and XMLRPC not win?

Soap was supposed to be the enterprisey safe superset of XML-RPC.

From my experience back at the beginning -- XML-RPC was slightly underspecified, and would have used a bit more of a firm hand about clarification of what was legal and what wasn't. SOAP was wildly overspecified and complexified to the point that you needed an army of consultants. Which is just perfect for enterprisey stuff, since you conviently have an army of consultants that need to have something to do.

IMHO, XMLRPC inhabited a middle ground that was washed away by REST and ajax/json type interfaces. It's an extra bit of complexity that's just not all that popular now, rather than a stunningly less complicated version of SOAP.

Re: SOAP: The 'S' stands for simple (not really)

#34

Post by didip »

wizard_2 wrote: post #30
jan_g wrote: post #11

Must be ~5 years since I last used SOAP. Needless to say I hated the stuff. Complex to build, complex to use (interoperability between different stacks - java/.net/... - was like 'cross your fingers and hope for the best'), complex to debug and walk through tcpdump network packets. It's complex in every way but the name. Of course, since that times I've alway advised against web services and so far I've succeeded in…

I'm being asked to create webservices so other developers don't do direct database access and their stuff wont break when things change. How do you manage that?

If you use MySQL, slap this bad-boy(http://code.nytimes.com/projects/dbslayer) between the app and the database.

The payload is JSON over HTTP.

Re: SOAP: The 'S' stands for simple (not really)

#35

Post by dansingerman »

wizard_2 wrote: post #30
jan_g wrote: post #11

Must be ~5 years since I last used SOAP. Needless to say I hated the stuff. Complex to build, complex to use (interoperability between different stacks - java/.net/... - was like 'cross your fingers and hope for the best'), complex to debug and walk through tcpdump network packets. It's complex in every way but the name. Of course, since that times I've alway advised against web services and so far I've succeeded in…

I'm being asked to create webservices so other developers don't do direct database access and their stuff wont break when things change. How do you manage that?

Designing an API is a skill in itself, but I think rule 1 is "Don't use SOAP"

JSON over REST seems to be flavour of the month FWIW.

Re: SOAP: The 'S' stands for simple (not really)

#37

Post by naba »

Sigh. this article made me a little sad. I keep wondering why the corporates who have all the money and resources keep using a technology that is just so old and has so many issues, when they have the better alternatives. My entire week was spent in just trying to get the configuration and a hello world service up and running.

Re: SOAP: The 'S' stands for simple (not really)

#38

Post by dedward »

It crosses some layer boundaries too.... having to manually edit (or I guess dynamically generate) wsdl files so that we can add a reverse proxy or load balancer in front of a webservice machine to access it several different ways in .net was definitely a pain in the butt.

Re: SOAP: The 'S' stands for simple (not really)

#39

Post by Rabidgremlin »

Love it. However at least SOAP is a spec and generally works.

REST is an architectural style there is no spec, just a idea! Added to that most folk also only build REST-like services.

Implementing a client for REST based services often requires a bunch of (generally simple) coding which takes time and is error prone.

Also pure REST is really good for building data access/CRUD services but makes it hard to build RPC type services without mangling the semantics.

Re: SOAP: The 'S' stands for simple (not really)

#40

Post by ph33t »

Let me preface this by saying I'm not particularly a microsoft basher, however this smacks of their history of interface development. Remember COM in the 90's? It was so complicated no one really knew how it worked. The only way to use it was to use a compiler that had native support for it ... MS Visual Studio and MS VB. Delphi came a long way quickly and made it work. Anyway whether intended or not, the result was you were initially tied to using a MS tool to use the technology. SOAP seems the same. Odds are if you're writing one end of it or another (client or server) somewhere the mix you're going to have a Microsoft tool. If you want to talk to the product of that Microsoft tool by far the easiest way will be to use a Microsoft tool. So despite being "open", their implementation of it ties you into some vendor-specific tools.
Post reply on HN