5 ms·

Ask YC: is SOAP vs. Rest the new Emacs vs. Vi?

9 points by c1sc0 19y ago

I've noticed the SOAP vs. REST - style webservice debate pop up again and again over the last few years. Which style of webservice do you prefer to offer/use? Why?

deleted 19y ago
[deleted]
inklesspen 19y ago
My view: SOAP is for people who bought the "XML is the universal language" line of bullshit. REST is for people who know how HTTP actually works.
- chrisbroadfoot 19y ago
  +1 That's not to say that there needs to be a war, there's no reason why both can't be implemented, though REST is definitely (as you assert) suited to HTTP.
- johnm 19y ago
  Naw. The de facto paylod for RESTful services are XML. Though, yes, that is called the POX (Plain Ol' XML) on REST. REST is the only thing that has been actually proven to work at internet scale. SOAP is just the latest version of CORBA, for the web.
  - inklesspen 19y ago
    Really? I've seen an awful lot of JSON services.
    - johnm 19y ago
      JSON is the "new hotness" for a lot of people but the default is still XML. Also, note that depending on what format the underlying data is in, using JSON can actually be worse for performance than POX (escaping, etc.).
bosky101 19y ago
i think u nailed it in the title yourself... 8 ) <humour> there are people who use soap,...and then there's the REST of us :D </humour>
Tichy 19y ago
I only ever see articles proclaiming REST is better. Maybe that is because my primary news source is news.yc.
- johnb 19y ago
  It's because no one uses REST and then choose to go back to spending days making java axis web services and .net clients play well together with ugly hackish custom soap extensions. Or maybe I'm just venting about my shitty week at work :)
  - c1sc0 19y ago
    Shitty week at work? Don't get me started ... that was the reason for this thread in the first place: an 'enlightened' architect imposing Axis/SOAP & then being surprised at the implementation-level problems.
    - geebee 19y ago
      I used Axis for some very minor work, and it wasn't too bad. I didn't get into SOAP at all, but it seemed like a good and (by java standards) lightweight way to turn a bunch of POJOs into web services quickly. What are some of the bad implementation problems you've experienced or heard about? Btw, I'm definitely not asking this to challenge the truth of your statement (ie., I'm not looking for a response to pick apart and argue - I would genuinely like to hear about some of the pitfalls you've seen).
      - c1sc0 19y ago
        I was initially impressed with the ease of converting some classes into SOAP requests with axis, but after a while we got random service outages & bad error handling. From previous experience in the biological field I saw great plans, lovely (& expensive) plans to develop grand services in SOAP ... that never actually materialized ... & were converted to REST spitting out standard files. I think the ideas of SOAP, WSDL & Co are actually very interesting but as a WS consumer I've come to shun SOAP services. In my opinion, human discoverability & excellent documentation are core to any webservice. Maybe throw in some example implementations or lightweight libraries specific to your service.
sah 19y ago
The reason that SOAP vs. REST isn't like Emacs vs. vi is that both Emacs and vi are pretty decent. Read the text of a SOAP transaction sometime. Or, more realistically, just read the first kilobyte or so. It's ridiculously over-engineered, and should just never be used. REST is a good example of how much simpler it could be.
c1sc0 19y ago
What about the documentation angle? SOAP supporters claim that WSDL removes the need for custom-written documentation if combined with something like javadoc. REST inherently needs more documentation which makes things harder to maintain. Or so they claim ;-) Anyone know a nice way to expose a webservice as SOAP/REST/XML-RPC & write the documentation automatically?
- wastedbrains 19y ago
  As a coder when ever working with API's code examples of how to call and actually use the API's was worth a lot more to me than a ton of documentation. The WSDL along with JAVA doc does give some good information about the available calls, but I think having a few client examples in a couple langauages would probably benefit more users.
  - c1sc0 19y ago
    I think one of the dirty little secrets of succesful api's is not in the API itself but in the example code / implementation libraries provided. Facebook had a great php lib initially & I see the ClickPass guys are providing lots of libraries on top of their API. Anyone else think just providing an API is not enough these days?
- johnm 19y ago
  Bah! The only thing that e.g. WSDL brings is that the "contract" for the service can be baked into the legal contract between partnering organizations. For big paranoid companies where people need a lot of CYA, that can be a big point. Good RESTful approaches are actually self-documenting. As the example from my recent talk on REST at SD West shows, it's really easy to support human discoverable (i.e., well documented) RESTful solutions. In my example, hitting the root resource returns a page (in html or text) that shows how to interact with the resource with actual examples. That's way better then some horribly verbose WSDL that somebody is going to have to look up.
  - andrewf 19y ago
    If someone's writing a client in an IDE, WSDL gets them code completion.
sanj 19y ago
It is more like Java vs. Ruby.
wastedbrains 19y ago
I am sure there are still some people fighting about it, but mostly what I have heard is REST won. Amazon says 80% of the api calls are REST, I believe Google has been moving more toward REST as well. After working with both (admittedly only a bit), I quickly decided REST was just far simpler. Is there specific reasons you see advantages in some SOAP capabilities that you don't think REST would handle well?
deleted 19y ago
[deleted]
andrewf 19y ago
I've implemented a small (in terms of number of supported calls) read-only web service which has SOAP+WSDL, REST/XML and REST/JSON frontends. From the server development point of view: SOAP is a giant pain. Randomly selected SOAP implementations are just not likely to interoperate. We eventually coaxed PHP5's SOAP server stuff into talking to both .NET 2.0 and Java (with Netbeans 5.5's J2EE libs) clients - IIRC we recommend SOAP 1.0 for one, and SOAP 1.1 for the other. A week after we finished Netbeans 6.0 was released, and the SOAP client stuff that's bundled with it wouldn't play well with our server. From the client end: /if/ you can actually talk SOAP successfully, things work nicely. You just call the generated stubs and the RPC happens transparently. If I was calling our web service from C# I would choose SOAP every time. The REST stuff would be a pain to use if you had to use the DOM to read the XML that comes back, because, well, the DOM is painful. If parsing what comes back isn't a pain, REST works well. For internal clients, we prefer REST/JSON with the standard PHP json parser.
benreesman 19y ago
Can someone please explain to me how REST is anything but a pompous name for HTTP? Or how it has applicability to any kind of service other than document management? All of the criteria stipulated in chapter 5 of the Fielding dissertation are spelled out in the RFCs that describe HTTP and related technologies, and _they only apply to documents_. There are other verbs that need to be applied over a network. I think the (sane) pro-REST argument can be summed up in the following: 'HTTP is a wonderful way to do CRUD operations over a network. Wouldn't it be cool if there was a catchy word to remind people that HTTP has a lot more to it than most people are aware of?'. This bollocks about REST being able to replace RPC is like having an argument about whether cars of airplanes are a better way to get around. And please stop torturing your service models to look like URLs just to be fashionable (I know, if I want upmod a comment I can POST to /comment/1234/karma/new! No, 'Upmod' is a distinct verb that doesn't have anything to do with GET or POST or PUT or HEAD or DELETE). If the thing you are modeling isn't a document in any sense, then don't try to model it as one. What I think people really mean when they say REST is 'ad-hoc RPC over HTTP using reasonably lightweight serialization', which is quite a lovely idea in its own right. The decision about using SOAP or a more lightweight RPC really boils down to the languages on each side of the wire. If the languages are structurally typed with object literal syntax then you want to use something lightweight, as the impedance mismatch between a literal Ruby datastructure and JSON is low. If you are connecting two nominally typed (often early bound) languages then you want SOAP, because if you're into that bondage and discipline thing then you need a WSDL to make sure that no one's boundaries get crossed. And pulling the result out of an HTTP response in Java is a lot easier with Axis than trying to parse some loosely specified JSON blob (unless you're coding in Perl, in which case I'll take the JSON blob any day). Don't debate SOAP/REST, if you must have some silly religious debate between two technology stacks which are both reasonable tools well suited to certain activities then at least debate Java/Python, the appropriate choice of RPC philosophy sort of falls out.
- johnm 19y ago
  Ouchy. Basically, it looks like you're taking a very narrow view of REST and conflating lots of it with historical RPC-ish thinking. Re: There are other verbs that need to be applied over a network. Please name one that's actually needed.

9 points by c1sc0 19y ago

I've noticed the SOAP vs. REST - style webservice debate pop up again and again over the last few years. Which style of webservice do you prefer to offer/use? Why?

deleted 19y ago

[deleted]

inklesspen 19y ago

My view: SOAP is for people who bought the "XML is the universal language" line of bullshit. REST is for people who know how HTTP actually works.

chrisbroadfoot 19y ago
+1 That's not to say that there needs to be a war, there's no reason why both can't be implemented, though REST is definitely (as you assert) suited to HTTP.
johnm 19y ago
Naw. The de facto paylod for RESTful services are XML. Though, yes, that is called the POX (Plain Ol' XML) on REST. REST is the only thing that has been actually proven to work at internet scale. SOAP is just the latest version of CORBA, for the web.
- inklesspen 19y ago
  Really? I've seen an awful lot of JSON services.
  - johnm 19y ago
    JSON is the "new hotness" for a lot of people but the default is still XML. Also, note that depending on what format the underlying data is in, using JSON can actually be worse for performance than POX (escaping, etc.).

bosky101 19y ago

i think u nailed it in the title yourself... 8 ) <humour> there are people who use soap,...and then there's the REST of us :D </humour>

Tichy 19y ago

I only ever see articles proclaiming REST is better. Maybe that is because my primary news source is news.yc.

johnb 19y ago
It's because no one uses REST and then choose to go back to spending days making java axis web services and .net clients play well together with ugly hackish custom soap extensions. Or maybe I'm just venting about my shitty week at work :)
- c1sc0 19y ago
  Shitty week at work? Don't get me started ... that was the reason for this thread in the first place: an 'enlightened' architect imposing Axis/SOAP & then being surprised at the implementation-level problems.
  - geebee 19y ago
    I used Axis for some very minor work, and it wasn't too bad. I didn't get into SOAP at all, but it seemed like a good and (by java standards) lightweight way to turn a bunch of POJOs into web services quickly. What are some of the bad implementation problems you've experienced or heard about? Btw, I'm definitely not asking this to challenge the truth of your statement (ie., I'm not looking for a response to pick apart and argue - I would genuinely like to hear about some of the pitfalls you've seen).
    - c1sc0 19y ago
      I was initially impressed with the ease of converting some classes into SOAP requests with axis, but after a while we got random service outages & bad error handling. From previous experience in the biological field I saw great plans, lovely (& expensive) plans to develop grand services in SOAP ... that never actually materialized ... & were converted to REST spitting out standard files. I think the ideas of SOAP, WSDL & Co are actually very interesting but as a WS consumer I've come to shun SOAP services. In my opinion, human discoverability & excellent documentation are core to any webservice. Maybe throw in some example implementations or lightweight libraries specific to your service.

sah 19y ago

The reason that SOAP vs. REST isn't like Emacs vs. vi is that both Emacs and vi are pretty decent. Read the text of a SOAP transaction sometime. Or, more realistically, just read the first kilobyte or so. It's ridiculously over-engineered, and should just never be used. REST is a good example of how much simpler it could be.

c1sc0 19y ago

What about the documentation angle? SOAP supporters claim that WSDL removes the need for custom-written documentation if combined with something like javadoc. REST inherently needs more documentation which makes things harder to maintain. Or so they claim ;-) Anyone know a nice way to expose a webservice as SOAP/REST/XML-RPC & write the documentation automatically?

wastedbrains 19y ago
As a coder when ever working with API's code examples of how to call and actually use the API's was worth a lot more to me than a ton of documentation. The WSDL along with JAVA doc does give some good information about the available calls, but I think having a few client examples in a couple langauages would probably benefit more users.
- c1sc0 19y ago
  I think one of the dirty little secrets of succesful api's is not in the API itself but in the example code / implementation libraries provided. Facebook had a great php lib initially & I see the ClickPass guys are providing lots of libraries on top of their API. Anyone else think just providing an API is not enough these days?
johnm 19y ago
Bah! The only thing that e.g. WSDL brings is that the "contract" for the service can be baked into the legal contract between partnering organizations. For big paranoid companies where people need a lot of CYA, that can be a big point. Good RESTful approaches are actually self-documenting. As the example from my recent talk on REST at SD West shows, it's really easy to support human discoverable (i.e., well documented) RESTful solutions. In my example, hitting the root resource returns a page (in html or text) that shows how to interact with the resource with actual examples. That's way better then some horribly verbose WSDL that somebody is going to have to look up.
- andrewf 19y ago
  If someone's writing a client in an IDE, WSDL gets them code completion.

sanj 19y ago

It is more like Java vs. Ruby.

wastedbrains 19y ago

I am sure there are still some people fighting about it, but mostly what I have heard is REST won. Amazon says 80% of the api calls are REST, I believe Google has been moving more toward REST as well. After working with both (admittedly only a bit), I quickly decided REST was just far simpler. Is there specific reasons you see advantages in some SOAP capabilities that you don't think REST would handle well?

deleted 19y ago

[deleted]

andrewf 19y ago

I've implemented a small (in terms of number of supported calls) read-only web service which has SOAP+WSDL, REST/XML and REST/JSON frontends. From the server development point of view: SOAP is a giant pain. Randomly selected SOAP implementations are just not likely to interoperate. We eventually coaxed PHP5's SOAP server stuff into talking to both .NET 2.0 and Java (with Netbeans 5.5's J2EE libs) clients - IIRC we recommend SOAP 1.0 for one, and SOAP 1.1 for the other. A week after we finished Netbeans 6.0 was released, and the SOAP client stuff that's bundled with it wouldn't play well with our server. From the client end: /if/ you can actually talk SOAP successfully, things work nicely. You just call the generated stubs and the RPC happens transparently. If I was calling our web service from C# I would choose SOAP every time. The REST stuff would be a pain to use if you had to use the DOM to read the XML that comes back, because, well, the DOM is painful. If parsing what comes back isn't a pain, REST works well. For internal clients, we prefer REST/JSON with the standard PHP json parser.

benreesman 19y ago

Can someone please explain to me how REST is anything but a pompous name for HTTP? Or how it has applicability to any kind of service other than document management? All of the criteria stipulated in chapter 5 of the Fielding dissertation are spelled out in the RFCs that describe HTTP and related technologies, and _they only apply to documents_. There are other verbs that need to be applied over a network. I think the (sane) pro-REST argument can be summed up in the following: 'HTTP is a wonderful way to do CRUD operations over a network. Wouldn't it be cool if there was a catchy word to remind people that HTTP has a lot more to it than most people are aware of?'. This bollocks about REST being able to replace RPC is like having an argument about whether cars of airplanes are a better way to get around. And please stop torturing your service models to look like URLs just to be fashionable (I know, if I want upmod a comment I can POST to /comment/1234/karma/new! No, 'Upmod' is a distinct verb that doesn't have anything to do with GET or POST or PUT or HEAD or DELETE). If the thing you are modeling isn't a document in any sense, then don't try to model it as one. What I think people really mean when they say REST is 'ad-hoc RPC over HTTP using reasonably lightweight serialization', which is quite a lovely idea in its own right. The decision about using SOAP or a more lightweight RPC really boils down to the languages on each side of the wire. If the languages are structurally typed with object literal syntax then you want to use something lightweight, as the impedance mismatch between a literal Ruby datastructure and JSON is low. If you are connecting two nominally typed (often early bound) languages then you want SOAP, because if you're into that bondage and discipline thing then you need a WSDL to make sure that no one's boundaries get crossed. And pulling the result out of an HTTP response in Java is a lot easier with Axis than trying to parse some loosely specified JSON blob (unless you're coding in Perl, in which case I'll take the JSON blob any day). Don't debate SOAP/REST, if you must have some silly religious debate between two technology stacks which are both reasonable tools well suited to certain activities then at least debate Java/Python, the appropriate choice of RPC philosophy sort of falls out.

johnm 19y ago
Ouchy. Basically, it looks like you're taking a very narrow view of REST and conflating lots of it with historical RPC-ish thinking. Re: There are other verbs that need to be applied over a network. Please name one that's actually needed.