Why Implementing Web Services using REST is better

Why Implementing Web Services using REST is better than SOAP Art Widmann Drexel University CS 575: Software Design Fall 2006

Introduction o Web Services n n n Allow systems in a heterogeneous environment to interoperate over a network Used by enterprise application vendors to leverage their legacy applications and provide next generation applications Implemented using SOAP or REST

Introduction o SOAP n XML-based Messaging Protocol o o n Service communication Operates over network protocols like HTTP Specifications o Industry support from major vendors like Microsoft and IBM through World Wide Web and OASIS Consortiums

Introduction o WSDL n n Web Service Description Language Service description o o o XML document Public interfaces Bindings to network protocols like HTTP

Introduction o Using a SOAP Web Service n Acquire WSDL o o o n n Service endpoint Available operations Message formats Create SOAP message Call the Web Service

Introduction o REST n Representational State Transfer o n Based upon Web Architecture o o n Roy T. Fielding Ph. D Dissertation HTTP Uniform Resource Identifiers (URI) Access and manipulate resources with small set of basic operations o Get, Modify, Create, and Delete

Introduction o Using a RESTful Web Service n n Access the Web Service via its URI Receive resource located at URI o XML Document n n n Available resources Schema for each resource Location (URI) of each resource Navigate to next resource Repeat

Why To Use Soap o Flexibility in design n n o Supports numerous operations Interface contracts Industry support n n Specifications Tools

Why To Use Soap o Extensible n n o Suite of WS-* Specifications Example – Reliable Messaging End-to-End Security n n Message content encryption WS-Security

Why To Not Use Soap o Flexibility in design n n o Unique set of operations Unique set of data structures Complexity n Many WS-* specifications o n Which ones to use? Specific SOAP tools required to build

Why To Not Use Soap o Extensible n n o WS-* Specifications REST could be extended too Security n WS-Security specification o n XML Encryption and XML Signature REST can use XML specifications directly

So Let’s REST o It’s all about the resources n Small set of basic operations via HTTP o n Consider SQL operations o n n GET, PUT, POST, DELETE SELECT, INSERT, UPDATE, DELETE Infinite resources accessible via URI Quite flexible

So Let’s REST o Easier to Develop n No need for specialized tools beyond o o o n HTTP to access network resources XML parsing of resources Web browser to debug Amazon. com o Provides both REST and SOAP services n REST services usage over 80%

So Let’s REST o Security n Provided by HTTP o Authentication and Authorization n o Operations on Resources can be secured System administration friendly n n Operation intent on Resource known SOAP only uses POST operation which hides the operation intent within the message

Conclusion o REST vs. SOAP n REST is simple o o n Fewer specialized tools Utilizes current Web Architecture SOAP is complex o o Additional tools required Number of specifications n n Some not finalized (e. g. , WSDL) REST is Network security friendly o Uses all of the HTTP operations

Conclusion o Towards a RESTful Future n Focus on standard methods of extending capabilities (e. g. , Reliable Messaging) o n n but keep it simple Design paradigm shift towards data resource manipulation rather than API invocation approach Integrate SOAP into REST o SOAP is a messaging protocol and REST operates on messages