Services Web Nabil Abdennadher

Services Web Nabil Abdennadher nabil.abdennadher@hesge.ch 1

Plan What is Web Services? SOAP/WSDL REST http://www.slideshare.net/ecosio/introduction-to-soapwsdl-and-restfulweb-services/14 http://www.drdobbs.com/web-development/restful-web-services-a-tutorial/ 240169069?pgno=1 2 http://rest.elkstein.org/2008/02/what-is-rest.html

Problem: What is the problem? How to communicate programs running on remote machines, different OS, different languages, developed by different companies? Solution Web services 3

Standard Web Site vs. Web Service Standard Web Site Human consumption Web Service Application consumption Get applications to talk to each other 4

What is a web service? A logical representation of a repeatable activity, that has a specific outcome A service is a type of API, usually over HTTP You may have an API, but not expose it to anybody external A service is a proxy of your internal logic, which is exposed to the outside world Think to the analogy of views in database systems http://www.slideshare.net/ecosio/introduction-to-soapwsdl-and-restful-web-services/14 5

Web Services Web services are based on http Firewalls are not longer a problem With Web Service, we can: Reuse application-components. Connect existing software: solve the interoperability problem by giving different applications a way to link their data. exchange data between different applications and different platforms. 6

Web Services WS semantically encapsulate functionalities and abstracts a program logic WS share a contract WS are described in term of standard langage description WS are loosely coupled modules WS are reusable WS are distributed over the internet HTTP, SNMP, FTP, etc. 7

SOAP/WSDL based Types of web services Service interface is exposed through WSDL documents Message exchange using SOAP Client code can be generated from WSDL description Representational State Transfer (REST) Easy way to communicate with web service Resources are identified by URIs and their state is manipulated through HTTP operations GET, POST, PUT, DELETE Rather a set of architectural principles, than a standard 8

SOAP https://www.youtube.com/watch?v=mkjvkplb1ra 9

SOAP Web Services : How does it work? Stages to use Web Service : We ask the Web Service its WSDL contract (Web Service Description Language) : a format (XML, W3C) that specifies what methods can be called on the Web Service. The web service returns its WSDL (methods, parameters, return values, etc.): The client creates a stub. During execution: Exchanged messages are based on SOAP protocol the client calls the desired method in accordance with WSDL and, retrieves the result of the call 10

11 Web services : How does it work?

SOAP and WSDL WSDL Defines the interfaces for remote services. Client Provides guidelines for constructing clients to the service. WSDL Tells the client how to communicate with the service. SOAP The actual communications are encoded with SOAP, transported by HTTP, SNMP, FTP, etc. SOAP Request WSDL SOAP Response Service

SOAP SOAP: Simple Object Access Protocol. Specifications : http://www.w3.org/tr/soap/ Created on Sept. 1998 (version 0.9) by Microsoft, UserLand and DevelopMentor 2000/2001 : version 1.2 with a working group composed of 40 companies SOAP consists on communicating XML messages embedded in a transport protocol (HTTP, SMTP, FTP, ) Describes how a message is formatted, but not how it s delivered? 13

14 WSDL Stands for Web Services Description Language Was developed jointly by Microsoft and IBM. Is a standard XML-based language for describing Web services and how to access them. WSDL serves as a contract between a service provider and a client invoking the service Describes how to access a web service and what operations it will perform: What a service does : the operations the services provides Where is resides: specific URL address How to invoke it : data formats, protocols necessary to access the services operations

WSDL Web service Web service WSDL interface WSDL interface SOAP messages Transfer protocol TCP/IP 15

Architecture Client site Container (Application server) Application 1 (.war file) User client code Stub client (generated by Web Service API) Web service runtime (CXF) Application 2 (.war file) Web service runtime (Axis) User classes User classes 16

REST Representational state transfer 17

History Doctoral dissertation (2000) of Roy Fielding. REST uses HTTP (or any other protocols) for all four CRUD (Create/ Read/Update/Delete) operations Architecture: Client-server, stateless, cacheable communication protocol, layered System. A service based on REST is called a RESTful service REST is an architectural style for designing networked applications. It simply uses the HTTP protocol to post, read and delete web data. -> lightweight. REST is not a "standard (no W3C recommendation for REST). REST is not dependent on any protocol but almost every RESTful service uses HTTP as its underlying protocol REST provides a definition of a resource. What is a resources??? 18

Resources Anything that can be referenced : pictures, video files, web pages, business information, or anything that can be represented in a computer-based system Is an abstract concept. It could be physical object. A resource can be a container to others resources. Identified by uniform resource identifier (URI) Resources are manipulated through their representations. Example: a web page is a representation of a page. 19

Features of a RESTful services Resources Representation Messages URIs Uniform interface Stateless Links between resources Caching 20

Resources representation (1) The focus of a RESTful service is on resources, links among resources, and how to provide access to these resources. Similar step of designing a database: Identify entities and relations. Once we have identified our resources, the next thing we need is to find a way to represent these resources in our system. You can use any format for representing the resources, as REST does not put a restriction on the format of a representation: XML, JSON, etc. 21

Resources representation (2) A web page is it a representation of a resource? yes the URI tells the client that there is a concept somewhere. The client requests a specific representation of the concept from the available representations that the server exposes. 22

Example of content negotiation request response 23

Resources representation (3) { } "ID": "1", "Name": "Mr Dupont", "Email": "first.name@gmail.com", "Country": CH" 24 <Person> <ID>1</ID> </Person> <Name>Mr Dupont</Name> <Email>first.name@gmail.com</Email> <Country>CH</Country>

Messages (1) : HTTP request VERB: GET, PUT, POST, DELETE, URI : URI of the resource on which the operation is going to be performed HTTP version : version of HTTP, generally "HTTP v1.1" Request header: metadata as a collection of key-value pairs of headers and their values: client type, formats client supports, etc. Request body: message content 25

Addressing resources (URIs) REST requires each resource to have at least one URI. A RESTful service uses a directory hierarchy like human readable URIs to address its resources. The URI should not say anything about the operation or action. Example: http://myservice/persons/1 This URL has following format: Protocol://ServiceName/ ResourceType/ResourceID 26

Uniform interfaces GET: Read a resource. PUT: Insert a new resource or update if the resource already exists. POST: Insert a new resource. Also can be used to update an existing resource. DELETE: Delete a resource. 27

Statelessness A stateless design looks like so: Request1: GET http://myservice/persons/1 HTTP/1.1 Request2: GET http://myservice/persons/2 HTTP/1.1 Each of these requests can be treated separately. A stateful design, on the other hand, looks like so: Request1: GET http://myservice/persons/1 HTTP/1.1 Request2: GET http://myservice/nextperson HTTP/1.1 28

Links between resources <Club> <Name>Authors Club</Name> <Persons> <Person> <Name>M. Vaqqas</Name> <URI>http://MyService/Persons/1</URI> </Person> <Person> <Name>S. Allamaraju</Name> <URI>http://MyService/Persons/12</URI> </Person> </Persons> 29 </Club>

Caching Caching is the concept of storing the generated results and using the stored results instead of generating them repeatedly if the same request arrives in the near future. This can be done on the client, the server, or on any other component between them, such as a proxy server. Caching is a great way of enhancing the service performance, but if not managed properly, it can result in client being served stale results. Caching can be controlled using HTTP headers 30

REST way of Implementing the web services (RESTful) HTTP Get request http://example.org/images q getimagelists() q getimagecontent(i d) Web server q deleteimage(id) q UpdateImage(id) q AddImage(id) 31

REST way of Implementing the web services (RESTful) HTTP Get request {"images": [{ "name":"lena1", "type":".jpg" }, { "name":"école", "lastname":"hepia"... http://example.org/images HTTP response (JSON) q getimagelists() q getimagecontent(i d) HTTP Get request http://example.org/images/2 Web server q deleteimage(id) q UpdateImage(id) q AddImage(id) 33

REST way of Implementing the web services (RESTful) HTTP Get request {"images": [{ "name":"lena1", "type":".jpg" }, { "name":"école", "lastname":"hepia"... http://example.org/images HTTP response (JSON) q getimagelists() q getimagecontent(i d) HTTP Get request http://example.org/images/2 HTTP response (image/png) Web server q deleteimage(id) q UpdateImage(id) q AddImage(id) 34

REST way of Implementing the web services (RESTful) HTTP Get request {"images": [{ "name":"lena1", "type":".jpg" }, { "name":"école", "lastname":"hepia"... http://example.org/images HTTP response (JSON) q getimagelists() q getimagecontent(i d) HTTP Delete request http://example.org/images/2 Web server q deleteimage(id) q UpdateImage(id) q AddImage(id) 35

REST way of Implementing the web services (RESTful) HTTP Get request {"images": [{ "name":"lena1", "type":".jpg" }, { "name":"école", "lastname":"hepia"... http://example.org/images HTTP response (JSON) q getimagelists() q getimagecontent(i d) HTTP Delete request <Image> <removed>true</..> http://example.org/images/2 HTTP response (text/xml) Web server q deleteimage(id) q UpdateImage(id) q AddImage(id) 36

REST way of Implementing the web services (RESTful) HTTP Get request {"images": [{ "name":"lena1", "type":".jpg" }, { "name":"école", "lastname":"hepia"... http://example.org/images HTTP response (JSON) q getimagelists() q getimagecontent(i d) HTTP Get request http://example.org/images/2 HTTP response (image/png) Web server q deleteimage(id) q UpdateImage(id) q AddImage(id) HTTP POST request http://example.org/images/3 Image_3 Image added successfully HTTP response (text) 37

Conclusion In few words.. What is REST?? A set of rules and conventions to reconstruct what you already know about the web (HTTP) in a clean, clear, maintainable, simple, extensible... design Question: Which is the best : SOAP or REST? 38

SOAP VS. REST SOAP: is based on XML. A SOAP message contains an envelope that defines the message content and how to parse it, a set of encoding role for data, methods signature and responses format. "generic" transport protocol: SOAP can use many of transport protocols like HTTP, SMTP, etc. SOAP is an industry standard: well-defined protocol and rules to be implemented. Can be used in large and small distributed systems. comes with pre-built structure to support many features like security, atomictransactions, coordination, etc. supports stateful operations (using sessions) is built-in error handling: the error message are well implemented.. supports WS-Atomic transactions for distributed execution: Example: moving money from one account to another is done into operation: (op1) removes money from account1 and (op2) puts money in account2. (op1) and (op2) are in the same transaction, i.e. if (op2) fails -> all the transaction fails. SOAP over HTTP uses POST request: data can not be cached or bookmarked. 40

SOAP VS. REST REST REST relies on a simple URL: uses the standard GET, PUT, POST,DETETE, HEADER HTTP operations. very easy to understand REST today uses HTTP/HTTPS Lack of standards and is considered an architectural approach is light: it works well for limited bandwidth and resources cases. the returned responses are defined by the developer. Any browser can be used for web service call. It supports also AJAX as bonus. supports only stateless operations. responses can be cached an bookmarked 41