An Overview of Web Services: SOAP and REST
Download as PPTX, PDF•7 likes•4,362 views
The document discusses the complexities of web services, focusing on both SOAP and RESTful architectures. It highlights the characteristics, advantages, and disadvantages of each approach while emphasizing the need to move beyond siloed enterprise applications through service-oriented architecture. Additionally, it provides a comparative analysis to help in choosing between SOAP and RESTful services based on specific use cases.
An Overview of Web Services: SOAP and REST
- 1. Web Services SOAP & RESTful ram awadh prasad
- 2. The Story of Winchester Mystery House
- 3. The Story of Winchester Mystery House • 160 rooms, 40 bedrooms, 6 kitchens, 2 basements and 950 doors • Of the 950 doors, 65 of them open to blank walls • 13 staircases were built and abandoned • 24 skylights were installed into various floors. • No architectural blueprint for the mansion was ever created.
- 4. Moving Beyond Application Silos • Most of Organizational structures today silo’ed. • Most enterprise applications also operate as silos. • Enterprise Data is scattered and “trapped” in the application silos. • Need a way to move beyond these Application Silos. • This is the key motivation for Service Oriented Architecture. Traditional Enterprise Applications CRM PURCHASE SALES CORPORATEWEBSITE
- 5. Paradigm Shift: Moving to SOA with Web Services Traditional Applications • Traditional applications are "silos • They have tight coupling • Applications across departments cannot talk • No effective data sharing Distributed Computing • Enabled different applications of a system to talk to each other • Supported by message-oriented middleware • Applications across different systems still cannot talk Web Services • Connecting enterprise applications • Standardized XML messages over HTTP • Allow application in a system talk with other applications in other systems
- 6. What is a Web Service? • A software system designed to support interoperable machine- to-machine interaction over a network. › Self-contained, modular, distributed, dynamic › Standardized messaging system › Can be described, published, located and/or invoked over the network. › Language-agnostic › Vendor and transport neutral Web Service
- 7. Characteristics of Web Services Characteristics Web Services Machine-to- machine interactions Loose coupling Interoperability Platform independence Operating system independence Leverage the architecture of the WWW
- 8. Why Web Services? • Glue application data silos: enable easier communications within and across organizations • Expose the functionality of existing applications e over the network – without application changes. • Loosely Coupled: Each service exists independently of the other services. • Service Reuse: A function coded once and used over and over • Low Cost of Communication: HTTP over existing internet
- 10. SOAP • An industry accepted W3C specification for XML distributed computing infrastructure. • Acronym for Simple Object Access Protocol (acronym not used now) • Extends HTTP for XML messaging and provides data transport for Web services • Enables client applications to connect to remote services and invoke remote methods • Driven by standard specifications › Basic: UDDI, WSDL, SOAP, XML & Namespaces › Extended: WS-Security, WS-Policy, WS-I (Interoperability) etc.
- 11. SOAP - Architectural Overview Discovery & Service Description Service Requester Service Requester Publish (WSDL) Find (WSDL) Service Provider Clients SOAP Response
- 12. SOAP: Basic Specifications • UDDI (Universal Description, Discovery, and Integration): Platform-independent way of describing and discovering Web services and Web service providers. • WSDL: Defines services as collections of network endpoints. • SOAP: Simple and lightweight mechanism for exchanging structured and typed information. • XML + Namespaces
- 13. Web Services Description Language (WSDL) • An XML format for describing information needed to invoke and communicate with a Web Service. It gives the answers to the questions › Who? › What? › Where? › Why? › How? • It describes the complete contract for application communication with the Web Service • A service description has two major components: › Functional Description: How the Web Service is invoked, where it’s invoked. Focuses on the details of the syntax of the message and how to configure the network protocols to deliver the message. › Nonfunctional Description: Details that are secondary to the message (such as security policy) but instruct the requestor’s runtime environment to include additional SOAP headers.
- 14. Understanding WSDL Structure A WSDL Document is a set of definitions with a single root element. Services can be defined using the following XML elements: • Type: Used to define custom message types (Data Type) • Message: Abstraction of request and response messages that my client and service need to communicate (Methods) • PortType: Contains a set of operations (Interfaces) which organize WSDL messages. • Binding: Binds the portType to a specific protocol (typically SOAP over http) (Encoding Scheme) • Port: provides physical address of the Service. • Service: Gives one or more URLs for the service many URLs
- 15. Understanding SOAP Message • XML message format for exchanging structured, typed data • Structured of following components: › 0 or 1 header elements › 1 body element › Envelop that wraps it all • Envelope : Root element of a SOAP message. • Header › Can contain additional payloads of “metadata” › Security information, quality of service, etc • Body: › Contains the XML payload › Can have optional Fault elements used to describe exceptional situations. • Attachment: MIME encoded for exchanging binary data. • Sample SOAP message
- 16. SOAP Demo
- 17. SOAP – Pros & Cons • SOAP Pros › Standard protocol for exchanging information in a decentralized and distributed environment. › Platform independent & Vendor neutral. › Simple compared to RMI, CORBA, and DCOM etc › Decouples the encoding and communications protocol. › Anything that can generate XML can communicate through SOAP. › Additional Security in addition to HTTP authentication or HTTPS. › Supported by most languages and tools. • SOAP Cons › Complex compared to RESTful Services › Higher learning curve › Being protocol heavy may lead to performance issues
- 19. RESTful Web Service • Representational State Transfer • REST is an architecture all about the Client-Server communication • Guided by REST constraints (design rules). • Based on Resource Oriented Architecture › A network of web pages where the client progresses through an application by selecting links › Requests/responses relate to representations of states of a resource › When client traverses link, accesses new resource (i.e., transfers state) • Uses simple HTTP protocol and service methods: › GET: Return data, nothing is changed on server › POST: Create, update, or delete data on server › PUT: Replace referenced resource(s) › DELETE: Delete referenced resource(s)
- 20. RESTful – Architectural Overview Service Requester Service Requester HTTP Request (XML/JSON) REST Web Server Clients HTTP Response (XML/JSON)
- 21. RESTful Design Specifications (Constraints) Client- Server • Separation of concerns - user interface vs data storage • Client and server are independent from eachother Stateless • Each request from client to server must contain all of the information • No client session data or any context stored on the server Cacheable • Specify data as cacheable or non cacheable • HTTP responses must be cacheable by the clients Uniform Interface • All resources are accessed with a generic interface (HTTP-based) which remains same for all clients. Layered System • Allows an architecture to be composed of hierarchical layers • Each component cannot “see” beyond the immediate layer. Code On- Demand • REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts.
- 22. HTTP Methods for RESTful Services HTTP Method URI CRUD Request Stream Response Stream Response Code POST /customers Create Customer without id customer 201 / 404 / 409 GET /customers Read n/a Customers collection 200 / 404 GET /customers/{id} Read n/a Customer 200 / 404 PUT /customers/{id} Update Customer n/a 200 / 204 / 404 DELETE /customers/{id} Delete n/a n/a 200 / 404 OPTIONS /customers/ Available Methods n/a Available Methods 200 / 204
- 23. RESTful Design Considerations Steps for designing RESTful Web Service • Identifying resources the service will expose over the network. • Designing the URI Templates – map URIs to resources • Applying the Uniform HTTP Interface – options available on each resource for different user groups. • Security Considerations – Authentication and authorization • Designing the Resource Representations – XML/JSON. • Supporting alternate Representations – XML or JSON based on filters • Providing Resource Metadata – Ability to discover resources and options • Avoiding RPC Tendencies
- 24. RESTful Design Considerations RESTful Service Implementation Considerations • Parse the incoming request to › Use URI to identify the resource. › Identify URI variables ( and map them to resource variables) › HTTP method used in the request (and whether it’s allowed for the resource). › Read the resource representation • Authenticate and authorize the user. • Use all of this information to perform the underlying service logic. • Generate an appropriate HTTP response, including › Proper status code › Description › Outgoing resource representation in the response entity body (if any).
- 25. RESTful Demo
- 26. RESTful – Pros & Cons • RESTful Pros › Simple interface (URI based) › Uses HTTP service methods (GET, POST, ...) › Caching can be leveraged for better performance › Small learning curve › Simple to test (browser compatible) › Less reliance on tools › No standard • RESTful Cons › Not yet well integrated into IDE’s (but getting better) › Security relies on HTTP authentication › Less reliance on tools › No standard
- 27. SOAP or RESTful?
- 28. Comparing: SOAP vs RESTful SOAP RESTful XML based Messaging Protocol REST is an architectural style Uses WSDL for communication between Consumer and Provider Uses XMl or JSON to send or receive data SOAP is Service Oriented – Invokes services by calling RPC methods REST is Resource Oriented - uses (generally) URI and methods like (GET, PUT, POST, DELETE) to expose resources SOAP supports for stateful implementation REST follows stateless model Transfer is over HTTP as well as other protocols such as SMTP, FTP, etc REST is over only HTTP SOAP is Distributed Computing style implementation REST is Web Style (Client Server) Implementation SOAP can be called from JavaScript but difficult to implement. Easy to call from JavaScript.
- 29. Which to choose, SOAP or RESTful? When to use SOAP When to use RESTful • Complex applications • Stateful operations • Formal Contracts • Asynchronous processing and invocation • Distributed applications in peer relationship • Additional security via WS Security • Authentication Tokens • XML Encryption • XML Digital Signatures • Relatively Simpler Applications • Stateless operations • Limited bandwidth and resources • Caching situations • Client Server mode • Only HTTPS security • Choosing between SOAP and RESTful – Architectural Decision, not just a matter of simplicity or performance.
Editor's Notes
- #3: The Winchester Mystery House - home to the heiress of the Winchester fortune (amassed from the sales of Winchester rifles). The heiress went to see a fortune teller and learned she was cursed to be haunted by the spirits of everyone ever killed by a Winchester rifle. The only way to avoid the curse was to build a mansion – as long as she kept building the spirits would leave her alone. She promptly hired 147 builders (and 0 architects), all of whom began working on the mansion simultaneously. The builders worked on the mansion until the heiress passed away, 38 years later.