What is the difference between REST and SOAP?


XML & Web services: What is the difference between REST and SOAP?

  1. What is the difference between REST and SOAP? (9 messages)

    I am trying to understand the rationale behind RESTful web services. From wikipedia, I know that RESTful proposes something like: http://example.com/users/{user} (one for each user) This is to find a user by the UserID or whatever the key is. But what if the request you want to send it to server composed with a form that includes parameters? or the UserID is a composite key of two IDs, how do you achieve this in REST? Besides, envelope includes subject, content and attachment are specified in SOAP. In SOAP envelope, you specify the function and gives the parameters. The function specifications are basically the interface of the web service. Anything underneath changes will not affect the clients. In the article "A RESTful Core for Web-like Applications Flexibility", Randy and Tom point out that if the implementation of the resource for specific URI changes, it will not affect the clients. But SOAP-based web services can do the same thing. As long as the interface (contract) do not change, clients are not affected. One may argue "what if the contract changes?", but isn't that URI is also the contract? If you are looking for the following URI: https://www.theserverside.com/users/johndoe And the resource has been changed from users to user, clients are affected. So my question is, what is the difference?
  2. REST has the support for sending parameters to the method/resource that gets invoked in the existing query parameters style like example.com/users/user1/address or example.com/users?userid=user1&sendme='address'
  3. REST has the support for sending parameters to the method/resource that gets invoked in the existing query parameters style like
    So let's say if I use GET, the server side is responsible to implement the logic to act on the params that are sent with the URI?
  4. Andy, Yes - in the system we are talking about in our article series, an HTTP request for http://example.com/users?userid=user&sendme=address is handled by the HTTP transport. Transports reside at the edge of a system and act as event detectors, when they detect an external event they process the event and issue an internal root request. The internal root request issued would be for the URI resource:/users+param@... with the verb SOURCE. The "..." above is a reference to a generated resource representation that contains an XML document with name-value-pairs. That document would be: user1 address This can be requested as an NVP object in which case the microkernel will transrept it to the proper representational form. From the perspective of the endpoint a code fragment that reads the information being sent from the browser would look something like: public void processRequest(Context context) throws Exception { NVP nvp = context.source("this:param", NVP.class); String userid = nvp.get("userid"); String sendme = nvp.get("sendme"); ... } -- Randy
  5. Andy, What we are saying in the article is that there are several types of client - service decoupling. If the interface of the service changes, then it is a simple matter to use logical-to-logical mappings to change requests issued by existing clients to the new service interface: old-pattern new-patterh There is also type decoupling within an ROC system. Specifically to your question about our statement in the article about changes. What we were trying to say is that the endpoint code that generates the resource representation can change without impacting any clients (and can be changed at runtime). We are also saying that the representational form returned can change without impacting clients. For example, let's say the first version returns a Boolean and then the second version returns either <b>t</b> or <b>f</b>. Clients won't have to change if there exists a transreptor that converts an XML document of that form into a Boolean object. The example you are using is external and with a small change you can use RESTful addressing and have version changes. Think of adding a level to the REST address to include a version number so ../users/v1.0/user/... and ../users/v2.0/user/... -- Randy
  6. Hi Randolph, Thanks for your reply. I still don't see why RESTful has no impact to clients while changes are made to the endpoint code. Let's assume the client side code never changes, it will submit request to specific URI with specific params and take params without translating (your e.g. boolean in XML). Now the client side has specifications. On server side the endpoint service will be developed based on client side specifications. So with your code provided: old-pattern new-patterh to implement new endpoint code is simply the code itself and change the "new-pattern" in the map and it will point to the new resource (I doubt that you actually want to do it in runtime but of course you can do that but watch out for synchronization problems because I am thinking of you changing the xml file directly so context will reload the file if it is changed). Isn't this the same as SOAP? As long as the endpoint service interface is the same, implementation can be changed (although this is not changed in runtime, I think this is a better way to reduce risk). Clients will not have to change unless the endpoint service interface is changed. You may say "Yes, so RESTful arch. is better because you just change the mapping, not the actual URI on client side". But you can do the same in SOAP. In REST, you hide the delegations to services behind the URI so the client side URI becomes logical address. Can't you just build a SOAP interface that is also a delegate so client side does not have to change WSDL at all?
  7. Randolph, I am sorry, I am still missing the point of the benefits of using REST over SOAP. Would you shed some lights on me please. Thanks in advance. Andy
  8. Yes andy, SOAP is better, :) ->REST reuses http security system, goes always over http, and try to reuse the http methods making an equivalence between your semantic operation and http methods (it is scandalous for me), it is not based upon "message" concepts. ->SOAP is good for standards (that means good interoperability). You can use it over SMTP, JMS and HTTP. You define your own operation with a name with meaning (AddCustomer vs HTTP POST in URL/customer means add a customer). SOAP is based upon "message" concept, SOAP has its own Security approach (WS-Security). SOAP messages can go through intermediate services (for some logic o tecnical reason), and without re-encrypting the message. SOAP has efficiency issues because of XML processing, But REST too!!! If you want efficiency and your application is inside an intranet, then use EJB with RMI over IIOP!
  9. REST vs. SOAP WebService[ Go to top ]

     The main advantages of REST web services are:

        * Lightweight  not a lot of extra xml markup
        * Human Readable Results
        * Easy to build no tool-kits required

    SOAP also has some advantages:

        * Easy to consume  sometimes
        * Rigid  type checking, adheres to a contract
        * Development tools

    via SOAP vs. REST
  10. Complex query and Transaction support?[ Go to top ]

    Asides from the obvious differences in style: strongly typed interface declaration vs ad hoc interface documentation, SOAP has the advantage of supporting complex queries and transaction supports:

    • For retrieval, one can send a request, in structured XML format, with long (read exceed URL limits) and complex conditions like "(age > 18 and country = US and not city = Las Vegas) or lastLogin between 1/1/2009 to 4/1/2009 and Number-of-posts < 10". Try that with URL.
    • For updates, you can stuff multiple objects possibly of different kind in one request, and so the SOAP server can commit the changes in one transaction. Try that with multiple REST post

    Anybody disagreed?