2

There is a huge discussion about Webservices using SOAP and RESTful Webservices. But i don't know precisely at which point does a Webservice which use WSDL, UDDI and SOAP not meet the REST Architecture ?

  • 1
    At point "0". SOAP doesn't meet any part of the REST architecture, and there's no reason that it should do so. – John Saunders Sep 05 '14 at 19:57
  • BTW, do you have a reason to wish that SOAP services met the REST Architecture? – John Saunders Sep 05 '14 at 22:58
  • no, i don´t have a reason to wish that SOAP services met the REST Architecture. I was interested about the differences in the Architectural styles. –  Sep 09 '14 at 11:45
  • SOAP is a protocol. It is not an architectural style. REST is not a protocol, it's an architectural style. – John Saunders Sep 09 '14 at 12:50

2 Answers2

-2

At most of the points. I have a more elaborate answer here. But to be short. I guess you are talking about SOAP webservices with RPC binding style... They are XML/RPC, while REST is REST. There are very specific REST constraints defined here: Architectural Styles and the Design of Network-based Software Architectures by Roy Fielding.

How a SOAP RPC webservice meets the REST constraints:

  • client-server architecture - always
  • stateless - possibly
  • cache - possibly
  • uniform interface - never
  • layered system - never
  • code on demand (optional) - possibly
Community
  • 1
  • 1
inf3rno
  • 24,976
  • 11
  • 115
  • 197
  • 1
    You seem to be very knowledgeable about SOAP, but your understanding of REST is not sufficient to make an objective comparison. – Chris Broski Sep 05 '14 at 19:50
  • Thanks for your opinion! Can you please elaborate? – inf3rno Sep 05 '14 at 20:17
  • 1
    You seem to be listing features of SOAP and then saying REST doesn't have them so it's different. This is not a fair comparison because REST architecture is not at the same level of specificity as SOAP. Your point #3 is the only accurate item. #2 is incorrect (many REST services are JSON, not hypermedia.) #7 is also incorrect (REST services can use cookies and persistent auth.) The other points are accurate about SOAP, but not explicitly specified for REST - URLs, authentication and other architecture specifics are left to the developer. – Chris Broski Sep 06 '14 at 00:53
  • Thanks the advice, but you are wrong. I edited my answer to make it cleaner for you. – inf3rno Sep 06 '14 at 11:33
  • Thanks for your extra detail (honestly) but you are still mostly wrong. I don't have a problem with #7 anymore because you corrected it from claiming REST is stateless. The two major misconceptions about REST you are still clinging to are 1) HATEOAS doesn't mean that non-hypermedia data is forbidden, just that a hypermedia response must be included a part of the service. 2) What the heck is an IRI? It certainly has nothing to do with REST and doesn't even make the [wikipedia disambiguation page](http://en.wikipedia.org/wiki/IRI) Please don't obfuscate with mystery TLAs. – Chris Broski Sep 06 '14 at 16:55
  • @protonfish: I believe that IRI is International Resource Identifier - a URI that allows non-ASCII characters. – John Saunders Sep 06 '14 at 18:19
  • @protonfish "if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API" - by Roy Fielding (the inventor of REST) HATEOAS is not an option, its a constraint. http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven – inf3rno Sep 06 '14 at 20:51
  • Ohh I never said, that non-hypermedia data is forbidden. I said only that if your client wants to navigate, then it has to use the links containing the IRIs given by the server, instead of trying to build IRIs on its own. – inf3rno Sep 06 '14 at 20:54
  • By REST your service can serve many kinds of resource representations. So it can serve non-hypermedia as well, but to access a specific (non-hypermedia or hypermedia) representation a REST client must use a link from a hypermedia representation. The only exception is the REST API root. So REST clients work just like browsers. You know the root, for example facebook.com, write in the address bar, and from that moment you use only links and forms to navigate. This behavior is purely intentional in REST. – inf3rno Sep 06 '14 at 21:03
  • @inf3rno: by that definition, I've never seen a REST API, or perhaps I've never seen a REST _client_ – John Saunders Sep 07 '14 at 00:45
-2

A REST service is defined by its interface. To be RESTful, it must have:

  1. Identification of resources
  2. Manipulation through representations
  3. Self-descriptive error messages
  4. Hypermedia as the engine of application state

SOAP does a decent job of the first 3, though it does significantly reimplement #2 and #3 so it is more verbose and less stable than relying on HTTP's underlying protocol. Where SOAP really diverges from REST is in #4 - HATEOAS. A properly designed REST service should be fully functional directly in a web browser. Admittedly, most purported "REST" services don't do this either, but it is at least possible. SOAP requires significant tools to use. (SoapUI is a decent one.)

Chris Broski
  • 2,421
  • 27
  • 23
  • 1
    -1: soap doesn't deal with resources or representations, and the "error messages" are not self-descriptive - faults are described by the WSDL, which is separate from the fault messages themselves. Note also that SOAP "tools" are often part of the environment in which SOAP is used, though I get your point that it's not very helpful in an environment with no tools. – John Saunders Sep 05 '14 at 20:01
  • SOAP has different definitions and terminology, yes, but it still handles addressing and manipulation of data in a fashion not entirely inconsistent with REST. – Chris Broski Sep 06 '14 at 00:46
  • 1
    Uh, no, it's totally unrelated to REST. – John Saunders Sep 06 '14 at 01:14
  • "Uh, no, it's totally unrelated to REST" Gee thanks, that was so informative. I'm convinced! – Chris Broski Sep 06 '14 at 16:44
  • 1
    REST is oriented to resources. SOAP has no orientation. It doesn't necessarily deal with resources by any description of resources, or data, or anything else specific. Recall also that SOAP can support either a document or an RPC model of communication. So, SOAP doesn't in any way "handle the addressing of data", because it has nothing to do with "data". – John Saunders Sep 06 '14 at 20:44
  • @JohnSaunders For what I know WSDL binds operations to IRIs and describes the input and output types with XSD. You can access the operations - you described in the WSDL file - through the SOAP protocol which can work over HTTP. So a SOAP webservice is usually RPC, and does not work with resources and representations, just SOAP messages and operation calls. I haven't worked with SOAP for years, so I don't know the document style binding, but according to IBM it certainly exists: http://www.ibm.com/developerworks/library/ws-whichwsdl/ – inf3rno Sep 06 '14 at 21:21
  • @protonfish The difference is much bigger than you describe, I don't think you fully understand either of the terms. A webservice which does not fulfill all of the REST constraint should not be called as REST. You can read about the REST constraints in the [Fielding dissertation](http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm), or you can read the short version in the "REST APIs must be hypertext-driven" titled [post of Fielding](http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven). Now since he is the author of REST I think you should respect his decisions. – inf3rno Sep 06 '14 at 21:29
  • @JohnSaunders Thanks the information about SOAP, I'll fix my answer. – inf3rno Sep 06 '14 at 21:30
  • @inf3rno: note that "IRI" means "International(ized?) Resource **Identifer**". It is not a resource _locator_. The hyperlinks in REST are intended to locate resources. The URI/IRI in WSDL is nothing other than an opaque identifier. It has no meaning. It could even be a UUID in some formats. – John Saunders Sep 06 '14 at 22:13
  • @inf3rno: Fielding may be the author of the PHD dissertation that first described REST, but authors do not control what becomes of their writing, or what use is made of it. For instance, if you insist that a service is not REST without HATEOAS, then I have to say that I have never seen a REST service. Can you give an example of one? I've been wanting to see one since HATEOAS was first described to me. – John Saunders Sep 06 '14 at 22:16
  • @JohnSaunders Here is a JSON-LD + Hydra [issue tracker example application](https://github.com/lanthaler/sfHydraDemoApp) by Markus Lanthaler. Hydra is a relative new project, and JSON-LD may be hard to understand if you don't know RDF well... Mike Amundsen wrote a simple proof of concept [maze application](http://amundsen.com/media-types/maze/) with a custom media type. Just by reading stackoverflow questions I think nowadays HAL+JSON applications with vendor specific media types are the most popular. I think it is not so hard to build a real REST application. – inf3rno Sep 06 '14 at 23:01
  • @JohnSaunders I don't know of any big REST applications, since I never tried to find one. I'd probably start by checking google applications. Ohh about the authority of Fielding. REST is similar to pizza. There is a very concrete [specification](http://www.fornobravo.com/vera_pizza_napoletana/VPN_spec.html) what is pizza and what isn't. And it's funny, but most of the products sold as pizza are not pizza... ;-) – inf3rno Sep 06 '14 at 23:08
  • 1
    @inf3rno: Actually, my point was that they are _all_ pizza, regardless of the "specification". In the same way, "REST" services are "REST" services not because they match the architecture in Fielding's dissertation, but because they are _called_ "REST" services. – John Saunders Sep 06 '14 at 23:13
  • @JohnSaunders Yepp, I understand your point of view, I guess that's why people use the RESTful term. It's like pizza and original italian pizza. ;-) Anyways they just misunderstood the Fielding dissertation, or never read it, because he emphasized that every REST constraint (except the code on demand) is mandatory. (I hope I used the right words :D) – inf3rno Sep 07 '14 at 03:50
  • This discussion has clearly gone off the rails. I wonder if you guys even remember what the question was? Something nobody has mentioned yet is that SOAP runs on top of HTTP - a protocol based on REST and authored by Roy Fielding - so it should be no surprise that SOAP relies quite a bit on REST. I have tried to be helpful so far but it is time to point out the elephant in the room: [SOAP](http://stackoverflow.com/questions/76595/soap-or-rest-for-web-services/7086147#answer-77018) [sucks](http://harmful.cat-v.org/software/xml/soap/) and should not be used by anyone. – Chris Broski Sep 07 '14 at 05:54