| | h1. REST vs. SOAP/WSDL |
| | |
| | I've had several blog postings comparing [REST|http://en.wikipedia.org/wiki/Representational_State_Transfer] with[SOAP|http://en.wikipedia.org/wiki/SOAP]/[WSDL|http://en.wikipedia.org/wiki/Web_Services_Description_Language]. They include some especially good comments from readers: |
| | * [Web Services: What is REST?|http://www.ibm.com/developerworks/blogs/page/woolf?entry=web_services_what_is_rest] |
| | * [Web Services: REST vs. SOAP/WSDL|http://www.ibm.com/developerworks/blogs/page/woolf?entry=web_services_rest_vs_soap] |
| | * [Web Services: REST isn't OO|http://www.ibm.com/developerworks/blogs/page/woolf?entry=web_services_rest_isn_t] |
| | * [Which is Most Common: SOAP or REST?|http://www.ibm.com/developerworks/blogs/page/woolf?entry=which_is_most_common_soap] |
| | * [Interoperability vs. Integration|http://www.ibm.com/developerworks/blogs/page/woolf?entry=interoperability_vs_integration] (became a discussion of strong interfaces (WSDL) vs. weak interfaces (REST)) |
| | * [typing rest|http://www.ibm.com/developerworks/blogs/page/pmuellr?entry=typing_rest] and [not doing REST|http://www.ibm.com/developerworks/blogs/page/pmuellr?entry=not_doing_rest] -- Patrick Mueller says REST needs typing/contracts/defined interfaces |
| | | * [WADL: Declared Interfaces for REST?|http://www-128.ibm.com/developerworks/blogs/page/woolf?entry=wadl_declared_interfaces_for_rest] |
| | | * [WADL: Declared Interfaces for REST?|http://www.ibm.com/developerworks/blogs/page/woolf?entry=wadl_declared_interfaces_for_rest] |
| | |
| | \\ |
| | h2. When to use what |
| | |
| | An emerging best practice seems to be: |
| | * Use REST for user interfaces and perhaps client apps, where a human is doing the work. These apps seem to be more forgiving: If the GUI messes up, the user notices and tries something else. REST can be especially useful with [Ajax|Ajax and Java], where simplicity is prized over correctness. |
| | * Use SOAP/WSDL for application integration, where apps are talking to each other without human intervention nor supervision. In this context, strong interfaces, provable correctness, and management and migration of service interfaces are prized over simplicity. |
| | |
| | So the question to be asked is: What if the interface changes and the integration breaks? If that's no big deal or easy to fix, use REST; otherwise, use SOAP/WSDL. |
| | |
| | \\ |
| | h2. Resources |
| | * "Ajax and REST" by [Bill Higgins|http://www.ibm.com/developerworks/blogs/page/BillHiggins] (developerWorks) |
| | ** [part 1: Advantages of the Ajax/REST architectural style for immersive Web applications|http://www.ibm.com/developerworks/xml/library/wa-ajaxarch/] |
| | ** [part 2: Meeting the challenges of Ajax software development|http://www.ibm.com/developerworks/java/library/wa-ajaxarch2.html] |
| | ** Bill's [REST thread|http://www.ibm.com/developerworks/blogs/page/BillHiggins?tag=rest] and [Ajax thread|http://www.ibm.com/developerworks/blogs/page/BillHiggins?tag=ajax] |
| | * [RESTful Service|http://ajaxpatterns.org/RESTful_Service] (AjaxPatterns.org) |
| | * "[Using REST with Ajax|http://www.onlamp.com/pub/a/python/2006/02/23/using-rest-with-ajax.html]" (O'Reilly) |
| | * _[Ajax and REST Recipes: A Problem-Solution Approach|http://www.apress.com/book/bookDisplay.html?bID=10188]_ (Apress) |
