Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Restful Fundamentals

182 Aufrufe

Veröffentlicht am

The objective of this presentation to understand basic concept of Rest Fundamentals and apply HTTP Methods in REST implementation

Veröffentlicht in: Bildung
  • Login to see the comments

Restful Fundamentals

  1. 1. REST Fundamentals – Applying HTTP Methods
  2. 2. REST Representational State Transfer
  3. 3. REST HTTP + Resource-Oriented Architecture
  4. 4. AGENDA - HTTP HTTP RESOURCE STATIC DYNAMIC URL RESOURCE LOCATOR RESOUCRE IDENTIFER VERBS GET POST PUT DELETE CONTENT TYPE MESSAGE HTTP REQUEST HTTP RESPONSE STATUS CODE 1xx - INFORMATIONAL 2xx - SUCCESSFUL 3xx - REDIRECTION 4xx – CLIENT ERROR 5xx – SERVER ERROR WWW HTML
  5. 5. WHAT IS THE WEB? An information system of interlinked hypertext documents and resources accessed via the Internet
  6. 6. HYPERTEXT DOCUMENTS
  7. 7. HYPERTEXT MARKUP LANGUAGE
  8. 8. AGENDA - HTTP HTTP RESOURCE STATIC DYNAMIC URL RESOURCE LOCATOR RESOUCRE IDENTIFER VERBS GET POST PUT DELETE CONTENT TYPE MESSAGE HTTP REQUEST HTTP RESPONSE STATUS CODE 1xx - INFORMATIONAL 2xx - SUCCESSFUL 3xx - REDIRECTION 4xx – CLIENT ERROR 5xx – SERVER ERROR WWW HTML
  9. 9. RESOURCES Anything that can be identified, named, addressed or handled on the Web
  10. 10. RESOURCE ▫ Can be concrete things: • Web Pages • Video files • Articles • Blogs • Image file
  11. 11. RESOURCE ▫ Can be static and dynamic
  12. 12. RESOURCE ▫ Can also represent abstract concepts • Employee or Product or Order • Time • Money Transfer • Calendar • User Accounts
  13. 13. AGENDA HTTP HTTP RESOURCE STATIC DYNAMIC URL RESOURCE LOCATOR RESOUCRE IDENTIFER VERBS GET POST PUT DELETE CONTENT TYPE MESSAGE HTTP REQUEST HTTP RESPONSE STATUS CODE 1xx - INFORMATIONAL 2xx - SUCCESSFUL 3xx - REDIRECTION 4xx – CLIENT ERROR 5xx – SERVER ERROR WWW HTML
  14. 14. URL Uniform Resource Locator  A URL is a specialization of URI that defines the network location of resource  URL defines how the resource can be obtained eg. http://some.domain.com/orderinfo?id=123
  15. 15. URL ANOTOMY UR I - Uniform Resource I d e n t i f i e r UR L - Uniform Resource L o c a t o r
  16. 16. RESOURCE IDENTFIERS A resource only exists on the Webif it has an identifier (URI)
  17. 17. RESOURCE NAMES ▫ URN - Uniform Resource Name • products/54321 • about-us • articles/web.html • posts/2015-01-12 • podcasts/rest.mp3 • products/9595
  18. 18. AGENDA HTTP RESOURCE STATIC DYNAMIC URL RESOURCE LOCATOR RESOUCRE IDENTIFER CONTENT TYPE VERBS GET POST PUT DELETE MESSAGE HTTP REQUEST HTTP RESPONSE STATUS CODE 1xx - INFORMATIONAL 2xx - SUCCESSFUL 3xx - REDIRECTION 4xx – CLIENT ERROR 5xx – SERVER ERROR WWW HTML
  19. 19.  HTTP can transfer any kind of information between clients and servers E.g. Text files, PDF, e-documents, images, videos, etc.  In any case, the data is streamed over TCP/IP and browser knows how to interpret the binary streams because of the HTTP protocol response header Content-Type CONTENT-TYPES
  20. 20. AGENDA HTTP RESOURCE STATIC DYNAMIC URL RESOURCE LOCATOR RESOUCRE IDENTIFER CONTENT TYPE VERBS GET POST PUT DELETE MESSAGE HTTP REQUEST HTTP RESPONSE STATUS CODE 1xx - INFORMATIONAL 2xx - SUCCESSFUL 3xx - REDIRECTION 4xx – CLIENT ERROR 5xx – SERVER ERROR WWW HTML
  21. 21. HTTP VERBS
  22. 22. AGENDA HTTP RESOURCE STATIC DYNAMIC URL RESOURCE LOCATOR RESOUCRE IDENTIFER CONTENT TYPE VERBS GET POST PUT DELETE MESSAGE HTTP REQUEST HTTP RESPONSE STATUS CODE 1xx - INFORMATION 2xx - SUCCESSFUL 3xx - REDIRECTION 4xx – CLIENT ERROR 5xx – SERVER ERROR WWW HTML
  23. 23. HTTP STATUS CODE  Ser ver ’s processed status corresponding to a request  Combination of numerical code & short description
  24. 24. AGENDA HTTP RESOURCE STATIC DYNAMIC URL RESOURCE LOCATOR RESOUCRE IDENTIFER CONTENT TYPE VERBS GET POST PUT DELETE MESSAGE HTTP REQUEST HTTP RESPONSE STATUS CODE 1xx - INFORMATIONAL 2xx - SUCCESSFUL 3xx - REDIRECTION 4xx – CLIENT ERROR 5xx – SERVER ERROR WWW HTML
  25. 25. HYPERTEXT TRANSFER PROTOCOL Server Client Yahoo.comMozilla Firefox
  26. 26. HTTP COMMUNICATION
  27. 27. HTTP MESSAGE - REQUEST Server Client Yahoo.comMozilla Firefox HTTP Request GET /HTTP/1.1 User-Agent: Mozilla Firefox Host: example.com Accept: */*
  28. 28. HYPERTEXT TRANSFER PROTOCOL ServerClient Yahoo.comMozilla Firefox HTTP Response HTTP/1.1 200 OK Content-Type: text/html Content-Length: 1270 <!doctype html> <html> <head> <title>Example Domain</title> </head> <body> … </body> </html>
  29. 29. HTTP request message is sent from the client (Brower) to HTTP Web-Server. Request message contain:  location of a resource or resource URI  HTTP method to use when accessing the resource.  Optional request headers (name-value pairs) providing additional information  Request body that identifies additional data to be uploaded to the server (e.g. form parameters, attachments, etc.) HTTP REQUEST MESSAGE
  30. 30. HTTP response message is sent from HTTP Web-Server back to the client (Web-Browser). Response message contain:  Carry status of processed request.  Provide response headers (name-value pairs) providing additional information about the response  Supplies optional response body that identifies additional data to be downloaded to the server (e.g. html, images, attachments etc. HTTP RESPONSE MESSAGE
  31. 31. HTTP MESSAGE FORMAT
  32. 32. Request Line HTTP MESSAGE FORMAT
  33. 33. /fruits/list?category=fruits&limits= 20 Path to resource Query string HTTP /1.1 HTTP HEADER – REQUEST LINE
  34. 34. Request/ Response General Header  Carry information about the HTTP transaction  Can be a part of request, as well as response General Headers HTTP HEADER – GENERAL
  35. 35. Request Header  Specific to an HTTP Request  Carry information about the client, and the type of request  Facilitates better understanding between client and server Request Headers HTTP HEADER – REQUEST
  36. 36. Request/ Response Entity Header  Carry information about the content  Mainly part of HTTP Response Entity Headers HTTP HEADER – ENTITY
  37. 37. HTTP REQUEST RESPONSE MESSAGE EXCHANGE
  38. 38. REST Representational State Transfer
  39. 39. REST HTTP + Resource-Oriented Architecture
  40. 40. REST HTTP + Resource-Oriented Architecture RESTful
  41. 41. What is REST?  REST is not a technology, nor a framework  REST is an architectural style - Set of principles & constraints Why constraints?  Constraints help us in developing applications that are “easy” to maintain and extend. REST
  42. 42. MAJOR PLAYERS
  43. 43. REST ACTORS REST RESOURCES REPRESENTATION ACTIONS
  44. 44. REST ACTORS REST RESOURCES REPRESENTATION ACTIONS
  45. 45.  In general, a RESTful resource is anything that is addressable over Web  Addressable = anything that can be accessed and transferred between clients and servers  Resource must have a unique address over the Web  Under HTTP these are URIs RESOURCES
  46. 46. In a RESTful web service, Resources are categorized as:  Singleton resource is a single chunk of information, similar to a row in a database table.  Collection resource is a set of resources with the same structure, similar to a selection of rows in a database table. RESOURCES MODEL
  47. 47. Uniform Resource Identifier  In a RESTful web service, It is a hyperlink to a resource  Means for clients and servers to exchange representations of resources ex. .../orderinfo?id=123  Only means to locate a specific resource  Used to negotiate representations of a given resource  In the url you give certain parameters that define which information you want the server to return to you (just like giving GET variables to a page). Server will respond you with a resource representation containing the information you’ve asked URIs
  48. 48. URIs are also used to link resources together. ex. URIs
  49. 49. REST ACTORS REST RESOURCES REPRESENTATION ACTIONS
  50. 50. Representation of resources is what is sent back and forth between clients & servers So, we never send or receive resources, only their representations REPRESENTATION
  51. 51.  Format of the representation is determined by the content- type  Interaction of the representation on the resource is determined by the action (GET, POST etc.) REPRESENTATION
  52. 52.  Different clients are able to consume different representations of the same resource A representation can take various forms, such as: • image • a text file • an XML stream • a JSON stream  Note: But its resource has to be available through the same URI REPRESENTATION FORMATS
  53. 53. REPRESENTATION FORMATS For human-generated requests through a web browser, a representation is typically in the form of an HTML page For automated requests from other web services, readability is not as important and a more efficient representation can be used such as XML or JSON
  54. 54. REST ACTORS REST RESOURCES REPRESENTATION ACTIONS
  55. 55. ACTIONS Actions are used to operate on resources For example, they can be used for – getting info about a movie – adding a photo to Flickr – deleting a file from a folder  Note: Data transmitted to and from the resource is a representation of it.
  56. 56. HTTP-BASED ACTIONS  Note: RESTful web services can also execute logic at the server level, but remembering that every result must be a resource representation
  57. 57. HTTP as Uninform Interface  Note: RESTful web services can also execute logic at the server level, but remembering that every result must be a resource representation
  58. 58. HTTP as Uninform Interface Restful Approach Traditional Approach Focus on resource names Focused on the actions to be performed on resources Four specific actions that we can take upon resources — Create, Retrieve, Update, and Delete (CRUD) Countless actions with no naming or implementation standards
  59. 59. HTTP as Uninform Interface
  60. 60. Artificial example of a web service handling students in some classroom Location of the service = http://restfuljava.com/ Resources are represented as XML streams CLASSROOM EXAMPLE
  61. 61. Student (identified by name): http://restfuljava.com/students/{name} List of students: http://restfuljava.com/students CLASSROOM EXAMPLE - URIs
  62. 62. Student Schema <student> <name>Jane</name> <age>10</age> <link>/students/Jane</link> </student> CLASSROOM EXAMPLE - REPRESENTATIONS
  63. 63. Students List: <students> <student> <name>Jane</name> <age>10</age> <link>/students/Jane</link> </student> <student> <name>John</name> <age>11</age> <link>/students/John</link> </student> </students> CLASSROOM EXAMPLE - REPRESENTATIONS
  64. 64. CLASSROOM EXAMPLE - REPRESENTATIONS GET POST PUT DELETE GET is used to RETRIEVE resources POST is used to CREATE resources PUT is used to UPDATE resources DELETE is used to DELETE resources No side effects Has side effects Has side effects Has side effects Can also return only parts of the resource The resource identity/URL is not known at creation time Return updated resource URL Used for Read operation and query
  65. 65. GET EXAMPLE
  66. 66. POST EXAMPLE
  67. 67. Theinitial GETis omitted here PUT EXAMPLE
  68. 68. DELETE EXAMPLE
  69. 69. REST Constraints 1. Uniform Interfaces – Resource Model • Every resource has a unique id which uniquely identify. • Every resource has URI [Uniform Resource Identifier]. URI Syntax URI
  70. 70. Resource URL Mapping with HTTP Method HTTP Methods Resource CRUD OperationsResource URI
  71. 71. REST Constraints
  72. 72. REST Constraints Uniform Interface
  73. 73. REST Constraints 1. Uniform Interfaces
  74. 74. REST Constraints 1. Uniform Interfaces - Resources
  75. 75. REST Constraints 1. Uniform Interfaces - Resource • Resource is a chunk of related information of an entity. • Can be static and dynamic. • Resources words are ‘NOUNS’ such as Movies, Employees, Products, Photos
  76. 76. REST Constraints 1. Uniform Interfaces – Resource Model • Singleton resource is a single chunk of information, similar to a row in a database table. • Collection resource is a set of resources with the same structure, similar to a selection of rows in a database table.
  77. 77. REST Constraints 1. Uniform Interfaces – Resource Model • Every resource has a unique id which uniquely identify. • Every resource has URI [Uniform Resource Identifier]. URI Syntax URI
  78. 78. REST Constraints 1. Uniform Interfaces – Resource Model Yahoo Social REST APIs Singleton resource : Following URI defines the profile resource for the user whose ID is 12345. https://social.yahooapis.com/v1/user/12345/profile The next URI specifies the connections (friends) for the user whose ID is 6677. https://social.yahooapis.com/v1/user/6677/connections Collection resource : Following URI accesses the collection of schools contained in the profile of the user of ID 98765. https://social.yahooapis.com/v1/user/98765/profile/schools
  79. 79. REST Constraints 1. Uniform Interfaces - Methods
  80. 80. Resource URL Mapping with HTTP Method HTTP Methods Resource CRUD OperationsResource URI REST Constraints
  81. 81. HTTP Methods
  82. 82. REST Constraints 1. Uniform Interfaces - Representations
  83. 83. REST Constraints Stateless
  84. 84. 2. Stateless Server Two types of State  Application State  Resource State REST Constraints
  85. 85. 2. Stateless Server  No client context is stored on the server between requests.  Each request from any client contains all of the information necessary to service the request, and any state is held in the client.  The server can be stateful, this constraint merely requires that server-side state be addressable by URL as a resource. REST Constraints
  86. 86. REST Constraints Application State Exchange of Request Identify between Server and Client
  87. 87. REST Constraints Resource State What is stored on the server (Beyond Session)
  88. 88. REST Constraints 2. Stateless Server  Each request contains ALL the information necessary to understand it  Application (session) state is kept on the client
  89. 89. REST Constraints 2. Stateless Server  Visibility - Performance  Reliability - Consistency  Scalability
  90. 90. REST Constraints Client Server
  91. 91. 1. Client - Server Separation of Concerns:  Client responsible for UI  Server responsible for data storage REST Constraints
  92. 92. 1. Client - Server REST Constraints + Scalability + Simplicity
  93. 93. REST Constraints Cache
  94. 94. REST Constraints 3. Cache  Clients are able to cache responses.  Responses must, implicitly or explicitly, define themselves as cacheable or not.
  95. 95. REST Constraints 3. Cache  Efficiency  Scalability  UP Performance
  96. 96. REST Constraints Layered System
  97. 97. AN EXMAPLE HTTP server: example.com
  98. 98. READING A TEXT RESOURCE http://example.com/hello-world.txt GET /hello-world.txt HTTP/1.1 Host: example.com HTTP Request
  99. 99. READING A TEXT RESOURCE http://example.com/hello-world.txt HTTP Response HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 13 Hello, World!
  100. 100. CREATING A TEXT RESOURCE POST / HTTP/1.1 Host: example.com Content-type: text/plan Hello Mars HTTP Request
  101. 101. CREATING A TEXT RESOURCE HTTP/1.1 201 Created Location: /hello-mars.txt HTTP Response
  102. 102. RESOURCE DOES NOT EXIST http://example.com/hello-world.txt GET /hello-world.txt HTTP/1.1 Host: example.com HTTP Request
  103. 103. RESOURCE DOES NOT EXIST HTTP/1.1 404 Not Found HTTP Response
  104. 104. EMPLOYEE RESOURCE  Name  Gender  Role
  105. 105. XML REPRESENTATION <employee> <name>Alice</name> <role>Developer</role> <gender>female</gender> </employee>
  106. 106. JSON REPRESENTATION { "name": "Alice", "role": "Developer", "gender": "female" }
  107. 107. HTML REPRESENTATION <h1>Alice</h1> <dl> <dt>Role:</dt> <dd>Developer</dd> <dt>Gender:</dt> <dd>Female</dd> </dl>
  108. 108. EMPLOYEE RESOURCE /employees/alice /employees/bob /employees/eve
  109. 109. RESOURCE OPERATIONS
  110. 110. LIST EMPLOYEE RESOURCES GET /employees HTTP/1.1 Host: example.com Accept: application/xml HTTP Request
  111. 111. LIST EMPLOYEE RESOURCES HTTP Response HTTP/1.1 200 OK Content-Type: application/xml <employees> <employee href="/employees/alice"/> <employee href="/employees/bob"/> <employee href="/employees/eve"/> </employee>
  112. 112. LIST EMPLOYEE RESOURCES HTTP Response HTTP/1.1 200 OK Content-Type: application/xml <employees> <employee href="/employees/alice"/> <employee href="/employees/bob"/> <employee href="/employees/eve"/> </employee>
  113. 113. READ EMPLOYEE RESOURCE GET /employees/alice HTTP/1.1 Host: example.com Accept: application/xml HTTP Request
  114. 114. READ EMPLOYEE RESOURCE HTTP Response HTTP/1.1 200 OK Content-Type: application/xml <employees> <name>Alice</name> <role>Developer</role> <gender>Female</gender> </employee>
  115. 115. CREATE EMPLOYEE RESOURCE HTTP Request POST /employees HTTP/1.1 Host: example.com Content-Type: application/xml <employee> <name>John</name> <role>QA</role> <gender>male</gender> </employee>
  116. 116. CREATE EMPLOYEE RESOURCE HTTP Response HTTP/1.1 200 OK
  117. 117. UPDATE EMPLOYEE RESOURCE HTTP Request PUT /employees/alice HTTP/1.1 Host: example.com Content-Type: application/xml <employee> <name>Alice</name> <role>Manager</role> <gender>female</gender> </employee>
  118. 118. UPDATE EMPLOYEE RESOURCE HTTP Response HTTP/1.1 201 Created Location: /employees/john
  119. 119. DELETE EMPLOYEE RESOURCE HTTP Request DELETE /employees/alice HTTP/1.1 Host: example.com Content-Type: application/xml
  120. 120. DELETE EMPLOYEE RESOURCE HTTP Response HTTP/1.1 204 NO Content
  121. 121. RESOURCE ORIENTED ARCHITECTURE  Addressability  Statelessness  Connectedness  Uniform Interface
  122. 122. ADDRESSSABILITY Every interesting piece of information the server can provide should be exposed as a resource, and given its own URI http://example.com/employees/alice
  123. 123. STATELESSNESS Every HTTP request should happen in complete isolation http://google.com/search?q=jellyfish
  124. 124. STATELESSNESS
  125. 125. STATELESSNESS http://google.com/search?q=jellyfish&start=10
  126. 126. STATELESSNESS Application State vs. Resource State
  127. 127. CONNECTEDNESS Documents should contain not just data, but links to other resources
  128. 128. CONNECTEDNESS
  129. 129. CONNECTEDNESS
  130. 130. CONNECTEDNESS
  131. 131. CONNECTEDNESS { "employees": [ "/employees/alice", "/employees/bob", "/employees/eve", ... ] "next_page": "/employees?start=10", "create_employee": "/employees" }
  132. 132. HATEOS Hypermedia As The Engine of Application State
  133. 133. REST Constraints

×