WWW Architecture. Software Architecture VO/KU ( / ) Denis Helic. KMI, TU Graz. Dec 7, 2011

Transcription

1 WWW Architecture Software Architecture VO/KU ( / ) Denis Helic KMI, TU Graz Dec 7, 2011 Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

2 Outline 1 Introduction 2 Quality requirements 3 Web architecture 4 Web Systems 5 Web Applications 6 Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

3 Introduction The Web Started as a static information system Hypermedia: documents linked into a web By following links users retrieve the documents Based on HTTP, HTML, URL (global addressing schema) All components very simple: the major reason for the huge success Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

4 Systems Rate of Growth Introduction Time to reach 50 million people Telephone 75 years Radio 35 years TV 13 years The Web 4 years Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

5 Introduction Functional Requirements Berners-Lee: Web s major goal was to be a shared information space through which people and machines could communicate. A way for people to structure their information Usable for themselves and others A way to reference and structure information provided by others Cross-platform, global scope Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

6 Quality requirements Quality attributes Usability: it must be very easy to use I.e. very easy to create, structure and reference information Participation was voluntary and it was the only possibility to attract the users Very error forgiving in structuring and referencing because of non-technical background of users Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

7 Quality requirements Quality attributes Technical simplicity: it must be very easy for developers to implement All components simple and text-based I.e the first version of HTTP: servers need to respond to the GET method HTML very simple: easy to write parsers and browsers URLs extremely simple Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

8 Quality requirements Quality attributes Extensibility: it must be easy to add new features The first versions of components very simple - improvements were needed User requirements change even in a closed environment In a global scope the change is only feature that does not change E.g. very soon users wanted to have search facility apart browsing - HTML forms were introduced Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

9 Quality requirements Quality attributes Scalability: it needs to match the Internet-scale More precisely: anarchic scalability The Internet is not under control of a single organization it is totally decentralized Need to continue operating when under an unanticipated load or malformed or maliciously constructed data Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

10 Quality requirements Quality attributes Anarchic scalability: consequences Clients cannot be expected to maintain knowledge of all servers Servers cannot be expected to retain knowledge of state across requests Documents cannot have back-links: the number of references to a resource is proportional to the number of people interested in that information Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

11 Quality requirements Development of The Web The original Web was not designed to meet all of the requirements and quality attributed defined above It lacked also an architectural vision at that time that would meet these ambitious requirements Web Consortium was founded to solve these problems A lot of researchers worked on defining an architecture to meet these needs Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

12 Web architecture Deriving the Web architecture Introducing constraints on the Web architecture to obtain an optimal solution to the requirements and quality attributes Each constraint will have advantages and disadvantages The whole design process is then a balancing process Optimization to obtain a best-match for the Web architecture Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

13 Client-server Web architecture Figure: Client-server style Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

14 Web architecture Client-server Separation of concerns Separates user-interface from data manipulation concerns Supports independent evolvability E.g. clients and servers can be developed independently and across organizational boundaries Supports Internet-scale attribute Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

15 Stateless Web architecture Figure: Stateless server Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

16 Web architecture Stateless Communication must be stateless in nature Each request from client must contain all the information needed to process that request I.e. it can not take advantage of session information stored on the server Session state is completely on the client Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

17 Web architecture Stateless Supports visibility, reliability and scalability Visibility: only look at a single request to determine the full nature of the request Reliability: it eases the task of recovering from partial failures Scalability: not having to store state between requests allows the server component to quickly free resources Scalability: simplifies implementation because servers do not need to manage information across multiple requests Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

18 Cache Web architecture Figure: Cache Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

19 Web architecture Cache Information can be labeled (by servers) as cachable If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests Improves efficiency, scalability, user-perceived performance Decreases reliability if the data does not match Midway: ask a server if the data has changed Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

20 Uniform interface Web architecture Figure: Uniform Interface Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

21 Web architecture Uniform interface Uniform interface between components Visibility of interactions is improves Simplifies the overall architecture Decouples implementations from the services Improves Internet-scale Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

22 Web architecture Uniform interface Uniform interface degrades efficiency Information is accessed and transferred in a standardized form rather than in an application specific form To define a uniform interface we need: Identification of resources (URL) Manipulation of resources through representations (HTML, recently XML) Self-descriptive messages (GET, POST, PUT, DELETE in HTTP) Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

23 Layered system Web architecture Figure: Layered system Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

24 Web architecture Layered system Improves Internet-scale Application composed of layers that are only aware of the neighbouring components not the complete system Bounds complexity and promotes indepency between components Supports scalability by introduction of proxies, shared-caches, gateways E.g. load-balancing behind a gateway Reduce user-perceived performance because they add processing overhead Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

25 Code on demand Web architecture Figure: Code on demand Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

26 Web architecture Code on demand Client functionality can be extended by downloading code E.g. Java applets, flash, JavaScript Improves extensibility Independent development Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

27 Types of Web Systems Web Systems Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

28 Web Systems The Web Two faces of the Web The Web as an application platform The Web as a huge distributed database Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

29 Web Applications Specifics of Web applications User requirements User interface and usability Application state and hypertext Addressability Architecture Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

30 Web Applications Application state on the Web: Hypertext Traditionally, application logic manages the application state E.g., the current state of the data, user inputs, etc. Typically, Web browser supports only HTML and does not have direct connection to the app logic Communication over network and HTTP with the app logic HTTP stateless (connection-less) Web server needs to track users and sessions Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

31 Web Applications Application state on the Web: Hypertext However, Web server provides only low-level tracking Responsibility of the app logic to manage sessions Manage it within the application server App server has other responsibilities as well Can lead to serious scalability problems Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

32 Web Applications Application state on the Web: Hypertext We can move session management to the client Manage it there with AJAX Other problems arise How to recover states with a new session: AJAX applications have typically single URLs How to recover previous state, i.e. browser back button problem Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

33 Web Applications Application state on the Web: Hypertext The solution is somewhere in the middle: manage only important states Manage those states with unique URLs E.g. each important application state has a new unique URLs Use linking to relate states to each other No management of the state on the server: no scalability problems No management of the state on the client: no recovery problems Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

34 Web Applications Application state on the Web: Hypertext Example: Google Maps Google Maps use Ajax to maintain permalink Any action that you execute changes the permalink The permalink is kept as a part of HTML This is the equivalent of the address bar Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

35 Web Applications Application state on the Web: Hypertext A little bit of extra DOM work keeps the permalink up to date as you navigate Every point on the map is a separate application state that has its own URL Application states were destroyed by Ajax but was put back by application design It allowed communities to grow around the Google Maps application Only because of proper management of application states with URLs! Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

36 Web Applications Addressability URL as the addressing schema E.g. /student/add /student/show /student/exam/add /student/exam/show Allow you to share application states for UI and services Just offer different content representations E.g. for UIs: HTML, for services: XML or JSON Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

37 Web Applications Addressability Advantages for humans (UIs) Meaningful, easier for humans Bookmarks Search engines can retrieve different parts and index it Advantages for service integration You might link services to each other Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

38 Web Applications Architecture: User-oriented database applications In traditional software engineering UODA are built with an N-tier architecture They started as 2-layer applications Data management layer and application/presentation layer Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

39 Web Applications Architecture: 2-layer applications Relational database as the Data Management layer Scripts (e.g. PHP) as application/presentation layer One and the same scripts implements application logic and the presentation (e.g. generating of HTML) Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

40 Web Applications Architecture: Problems of 2-layer applications Mixture of application and presentation related functionality Changes in application logic lead to changes in presentation functionality and vice versa E.g. changing a table that present some application data leads to changes in the return values of some application specific functions Even more dangerous the presentation layer talks directly to the DML Better modularity is achieved with the third layer Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

41 Web Applications Architecture: 3-layer applications Separation between Application and Presentation layer No direct connection between Presentation and Data Management Decoupling of Application and Presentation layer Possibility to exchange Presentation layers The best example: making a Web gateway to an existing application The old GUI (e.g. a standalone GUI) is replaced with a Web GUI Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

42 Web Applications Architecture: 3-layer applications Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

43 Web Applications Architecture: 3-layer applications Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

44 Web Applications Architecture: 3-layer applications Presentation tier: HTML, templates and scripts to generate HTML Application logic tier: the actual application Data access tier: manages persistent app data Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

45 Web Applications Architecture: 3-layer applications With introduction of AJAX different possibilities where to situate tiers E.g. presentation in browser: HTML + (presentation) JavaScript, Application and data access on server E.g. presentation and app in browser: HTML + (presentation and application) JavaScript, data access on server Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

46 Web Applications Architecture: 3-layer applications Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

47 Web Applications Architecture: 3-layer applications There are numerous architecture variants built on the top of N-tier architectures The most important for Web applications: Model-View-Controller architecture It was invented in the early days of GUIs To decouple the graphical interface from the application data and logic Very useful also for Web applications Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

48 Web Applications Architecture: Data Management Typically, Web applications deal with relational databases Need to manage relational data in object-oriented applications Use design patterns like Data Access Object (DAO) Use object/relational mapping, like Hibernate framework Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

49 Web Applications Architecture: Data Management Information retrieval How to find what I m looking for? One approach are search engines with full-text processing Another approaches analyze links Links in databases, or within documents Mixed approach: full-text and links, e.g. Google Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

50 Web Applications Architecture: Data Management Yet another approach is managing metadata Metadata is data about other data On the web Tag information items (everything that you can access via URL) in a structured manner Search inside metadata Social Web 2.0 applications or Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

51 Web as a database The Web we use is full of data Book information, opinions, prices, arrival times, blogs, tags, tweets, etc. The data is organized around a simple data model: node-link model Each node is a data item that has a unique address and a representation Representation formats are e.g. HTML, PDF,... for humans, or e.g XML, JSON for programs Nodes can be interlinked using their unique addresses Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

52 Web as a platform for distributed systems The Web is full of services that allow humans and programs to use the Web data Service also have unique addresses They use a particular representation for data exchange, e.g. XML, SOAP, WSDL Services follow a particular architecture that defines how services are used Programmers combine a number of services to achieve a desired functionality and create a distributed system, e.g. mashups Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

53 Types of services What is the Google search engine? It is a service for querying a massive database (Web search index) What is a given Web application? It is a service offering (remotely) a specific functionality What is a Web site? It is a service offering specific human consumable information Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

54 Types of services All of these services are for users However, we are interested in services for programmers Such services provide an API Programmers use the API, unique addresses, representations of services Programmers follow the arch. style to integrate and combine services to achieve a desired functionality We will call this part of the Web: the programmable Web Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

55 Kind of Things on the Programmable Web There are numerous approaches to web services in all areas The programmable Web is based on HTTP for data transport and in most cases XML for data representation However, some services serve HTML, JSON, plain text, binary data, etc. Also, other things such as addressability or APIs are different We need a classification! Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

56 Classification based on architectural design Which operation should a service execute? This is method information What data should be manipulated? This is scoping information Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

57 Method information Question: how the client conveys its intention to the server? How does a server know a certain request is a request to retrieve some data? Instead of a request to delete the same data? Why should the server do this instead of doing that Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

58 Method information First alternative Convey method information by putting it in the HTTP method GET, DELETE, PUT, POST Semantics is clear It is standardized Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

59 Method information Second alternative: e.g. Flickr services search&tags=penguin addtags&... deletecomment&... Method information is in a query variable, all methods use GET (although some change the data) Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

60 Method information Third alternative: SOAP and WSDL Method information is in the SOAP message encoded as defined by a WSDL wsdl_uri = driver = SOAP.create_rpc_driver(wsdl_uri) result_set = driver.dogooglesearch(...) Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

61 Method information POST search/beta2 HTTP/ <soap:envelope> <soap:body> <gs:dogooglesearch> <q>rest</q> </gs:dogooglesearch> </soap:body> </soap:envelope> Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

62 Method information <operation name="dogooglesearch"> <input message="typens:dogooglesearch" /> <output message="typens:dogooglesearchresponse" /> </operation> Method information defined in WSDL and used in SOAP and via SOAP-framework in the code HTTP method is always POST Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

63 Scoping information Question: How the client tells the server on which data to operate? E.g. the server knows that the client wants to delete some data, but which data is it? Why should server operate on this data instead of that data? Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

64 Scoping information First alternative: as query variables in URL Scoping information is q=rest Method information is in GET Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

65 Scoping information Yet another example Flickr Most of the query variables are scoping information tags=penguin Recollect that Flickr also includes method information in query variables Thus, URL contains a method and a number of arguments for that method Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

66 Scoping information Second alternative: scoping information in the body of a SOAP message POST search/beta2 HTTP/ <soap:envelope> <soap:body> <gs:dogooglesearch> <q>rest</q> </gs:dogooglesearch> </soap:body> </soap:envelope> Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

67 Competing Architectures RESTful, Resource-Oriented Architectures RPC-Style Architectures REST-RPC Hybrid Architectures Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

68 RPC-Style Architectures RPC - Remote Procedure Call An RPC style service receives an envelope full of data from the client The service answers with a similar envelope again full of data to the client Both method and scoping information are inside of the envelope HTTP methods typically POST but sometimes also GET Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

69 RPC-Style Architectures The best example of the envelope format is SOAP There exist other envelope formats like XML-RPC Every RPC-style service defines a completely new vocabulary E.g. the way how method information and scoping information are represented You need another language to define the representation: e.g. WSDL Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

70 Problems of SOAP/WSDL RPC implies an API APIs tend to enforce tight coupling of modules and systems We use declarative XML to describe APIs This introduces processing overhead Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

71 Problems of SOAP/WSDL APIs and there definitions in some language e.g. WSDL introduce new vocabulary and hence a new addressability schema This is a big problem for service integration, in particular for automatic integration Each service needs to understands what all other services provide and how to address the functionality But where are URLs, links, representations? All the nice Web elements that made it successful! Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

72 RESTful, Resource Oriented Architectures RESTful services look like the Web Method information goes into into the HTTP method Scoping information goes into the URL If the method information is not in HTTP method - the service is not RESTful If the scoping information is not in the URL - the service is not RESTful Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

73 Some examples of RESTful services Services that expose Atom Publishing Protocol, such as GData Amazon s Simple Storage Service S3 Most of Yahoo! s web services Static web sites Many web applications, especially read-only such as search engines Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

74 Clients for RESTful services In principle clients are simple HTTP clients When you program a client you need an HTTP library In most cases you will need an XML library to parse the response Programatically, clients are in a typical case extremely simple Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

75 Client for a RESTful service - Example Example using Simple Storage Service - S3 S3 allows you to store any data you like using different structures S3 is based on two concepts: buckets and objects A bucket is analogous to the filesystem An object is analogous to a file Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

76 Client for a RESTful service - Example S3 service exposes three resources that you can manipulate The list of your buckets A particular bucket A particular object inside a bucket Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

77 Client for a RESTful service - Example Every resource exposes the same interface and works in the same way To get an object s value you send a GET request to the object s URL To get only object s metadata you send a HEAD request to the same URL To add an object to a bucket you send a PUT request to a URL that has the bucket name and the object s name Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

78 Client for a RESTful service - Example HOST = doc = REXML::Document.new(open(HOST).read) REXML::XPathj.each(doc, "//Bucket/Name") do e buckets << Bucket.new(e.text) if e.text end return buckets Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

79 Client for a RESTful service - Example <Buckets> <Bucket> <Name>crummy.com</Name> <CreationDate>...</CreationDate> </Bucket>... </Buckets> Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

80 Resource Oriented Architectures 4 defining features of ROA Addressability: the scoping information is kept in the URL Uniform interface: the method information is kept in the HTTP method Statelessness: every HTTP request is isolated from other requests Connectedness: you link resources into the Web of resources Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

81 Addressability Resources are exposed through URLs - an application exposes a number of URLs When you have URLs you bookmark, cache responses, chain URLs,... Many Web applications do not work this way, i.e. they are not addressable, e.g. GMail Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

82 Uniform interface Standardized HTTP methods: CRUD operations Two principles Safety: GET only reads data Idempotence: the same operation has the same effect wheter you apply it once or multiple times Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

83 Statelessness Every request contains all necessary information There is no state managed on the server side In fact, there are two kinds of state You should distinguish between the application state and resource state Application state lives on the client Resource state lives on the server Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

84 Statelessness When you use a search engine your current query and your current page belongs to application state They are different for every client Resource state is same for every client, i.e. search index A crawler can update the search index Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

85 Links and connectedness Representations of resources, i.e. HTML or XML might have links to other resources Axiom for REST services: Hypermedia as the engine of application state The current application state is not stored on the server as a resource state It is tracked by the client as an application state and created by the path that client takes through the Web Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

86 Links and connectedness For example The first page is the starting application state You have links to other application states Obvious for the human Web Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

87 Links and connectedness <Buckets> <Bucket> <Name>crummy.com</Name> <URL> <CreationDate>...</CreationDate> </Bucket>... </Buckets> Following the link in the URL element takes the client to a new application state Use links, links, and then use more links,... Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

88 Designing RESTful services Figure out data set Split the data set into resources Then, for each resource Name the resources with URLs Expose a subset of the uniform interface Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

89 Designing RESTful services Design representations accepted from the client Design representations served to the client Integrate this resource into other resources using links Consider possible application states Consider possible error states Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

90 Example Application similar google maps: maps of cities, streets, planets,... Data set: Maps, points, cities, planets,... Resources: list of resources, individual resources, results of algorithms applied to the data set Example resources: the list of planets, Mars, Earth, San Francisco, Inffeldgasse,... An algorithmic resource: a list of places that match certain criteria - all cities with more than 1 million of people Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

91 Example Name the resources: create meaningful URLs Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

92 Example Design representations A representation talks about resource state A representation links to other (application and resource) states Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

93 Read/Write RESTful services User accounts should be resources To access these resources you need to use HTTP authentication Connect with the previous resources: e.g. custom places on a map Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

94 RESTful frameworks Ruby on Rails with a plugin Django in Python Restlet in Java ( Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

95 Restlet example public Restlet createroot(){ Router router = new Router(getContext()); router.attach("/users/{username}", UserResource.class); router.attach("users/{username}/bookmarks", BookmarksResource.class); router.attach("users/{username}/bookmark/{url}", BookmarkResource.class); } Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

96 Restlet example public UserResource(Context context, Request request, Response response){ super(context, request, response); username_ = (String) request.getattribute(). get("username");... getvariants().add(new Variant(MediaType.TEXT_PLAIN)); } Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

97 Restlet example public Representation getrepresentation(variant variant){... if(variant.getmediatype().equals(mediatype. TEXT_PLAIN)){ result = "-----User details ";... } return result; } Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

98 REST Web service: Example To create a REST Web service the following steps should be accomplished Define URLs Define XML vocabulary Define which methods are available at each URL Define HTTP status codes Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

99 REST Web service: Example Defining URLs Recollect the clean URLs that we have discussed before Course with ID 1: Course with ID 2: All courses: Note that URLs are regular, i.e., we can automatically construct them Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

100 REST Web service: Example Defining XML formats Single course <?xml version="1.0" encoding="utf-8"?> <course> <title>mmis2</title> <url> <id type="integer">1</id> <description>advanced course on multimedia information systems</description> </course> Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

101 REST Web service: Example All courses (collection) <?xml version="1.0" encoding="utf-8"?> <courses> <course> <title>mmis2</title> <url> <id type="integer">1</id> <description>advanced course on multimedia information systems</description> </course> <course>...</course> </courses> Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

102 REST Web service: Example Defining methods GET and POST GET retrives the list, POST adds another course to the list GET, PUT, DELETE PUT updates the course Additionally, send OPTIONS at each URL to see what is available Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

103 REST Web service: Example Defining HTTP status codes GET: HTTP/ OK POST: HTTP/ Created PUT, DELETE: HTTP/ No Content Error code: HTTP/ Internal Server Error Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

104 REST Web service: Example We need a Web server that can dispatch URLs and HTTP methods to appropriate code Within that code we manipulate resources using their XML representations With Rails we can also dispatch URLs easy Recollect that Rails dispatch to a class and a method within that class We need to dispatch to a class and according to the HTTP method Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

105 REST Web service: Example There is a Rails plugin that does exactly that RESTful Rails controller class CourseController < ApplicationController include RestController::Base... end Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

106 REST Web service: Example The plugin allows you to introduce resources and within resources handle HTTP methods resource :collection do r conditions = Course.find_all end r.post do... end GET method is automatically handled and connected with appropriate XML-based view Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

107 REST Web service: Example collection.rxml in views directory xml.instruct! xml.courses do xml.title do course xml.course do xml.id course.id xml.title course.title xml.url course.url xml.description course.description... end end end Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

108 REST Web service: Example Handling POST to the collection (adding a course) r.post = Course.new params[:course] render_post_success :action => by_id, :id end end Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

109 REST Web service: Example Handling of single courses (introduce a new rule by id) resource :by_id do r conditions = Course.find(params[:id]) end r.put = params[:course] render_put_success end end Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

110 REST Web service: Example Deleting a resource... r.delete do render_delete_success :id => nil end end... Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

111 REST Web service: Example GET XML view Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

112 REST Web service: Example Demo: rest_courses.zip curl curl curl -i -X POST -d <course><title> Web Information Systems</title></course> curl -i -X PUT -H Content-Type: application/xml -d <course> <title>web Information Systems</title> <description>very advanced course</description> </course> curl -i -X DELETE Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

113 REST-RPC Hybrid Architectures (1) Services somewhere between RESTful and RPC services search&tags=penguin Both method and scoping information is in URL HTTP is used as an envelope format Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

114 REST-RPC Hybrid Architectures (2) GET services/rest?method=flickr.photos.search& tags=penguin HTTP/1.1 Host: Another prominent example of this style is del.icio.us Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

115 Programmable Web Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

116 Programmable Web Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

117 Further Readings What is Service-Oriented Architecture? A Primer webservices/index.html Top Ten FAQs for webservicefaqs.html?page=1 Service-Oriented Architecture and : Concepts, Technologies, and Tools WebServices/soa2/index.html Articles on from O Reilly Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118

118 Further Readings REST definition (PhD Thesis of Roy Fielding) rest_arch_style.htm The Restful Web: Column on xml.com Putting REST on Rails REST vs SOAP: Second Generation Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, / 118