Tohuwabohu excorcism

User Tools

Site Tools

Trace: • elasticache • dynamodb
rest

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rest [2018/02/28 14:40] – [What makes REST different from SOA or HTTP-based interfaces] skipidarrest [2023/06/06 09:53] (current) – skipidar
Line 6: Line 6:
 Es werden Methoden übergeben: Es werden Methoden übergeben:
  
-| |GET | POST | PUT | DELETE| PATCH| +|          | GET | POST | PUT | DELETE| PATCH| 
-|Safe|x| | | | | +|Safe      |  x  |      |     |       |      | 
-|Idempotent|x|x| |x| |+|Idempotent|  x  |      |  x  |  x    |      |
  
  
Line 14: Line 14:
  
 A good describtion is here: \\ A good describtion is here: \\
-http://www.se.uni-hannover.de/pub/File/kurz-und-gut/ws2011-labor-restlab/RESTLab-HTTP-Serhat-Esen-kurz-und-gut.pdf+https://restfulapi.net/idempotent-rest-apis/
  
  
Line 25: Line 25:
  
  
-===== compare REST vs just some HTTP based interface ======+===== Maturity of REST ======
 {{https://martinfowler.com/articles/images/richardsonMaturityModel/overview.png}} {{https://martinfowler.com/articles/images/richardsonMaturityModel/overview.png}}
  
  
-==== What makes REST different from SOA or HTTP-based interfaces ====+==== What makes REST architecture mature? 4 steps ====
 https://martinfowler.com/articles/richardsonMaturityModel.html https://martinfowler.com/articles/richardsonMaturityModel.html
  
Line 61: Line 61:
 </code> </code>
  
 +
 +
 +=== Glossary === 
 +| Compound Documents | <WRAP> 
 +To reduce the number of HTTP requests, servers MAY allow responses that include related resources along with the requested primary resources. Such responses are called “compound documents”.
 +https://jsonapi.org/format/#document-compound-documents 
 +</WRAP> |
 +|Sparse Fieldsets| A client MAY request that an endpoint return only specific fields in the response on a per-type basis by including a fields[TYPE] parameter. <code>GET /articles?include=author&fields[articles]=title,body&fields[people]=name`</code> |
  
  
Line 70: Line 78:
 Characteristics: Characteristics:
   * tunneling a mechanism for an own RPC - remote interaction mechanism. **But to special URIs** - not one service.   * tunneling a mechanism for an own RPC - remote interaction mechanism. **But to special URIs** - not one service.
-  * **using Resources**. On the URI too like **/doctors/mjones** or  **/slots/1234/appointment**. Collections are for listing resources. Concrete resources are for getting details.+  * **using Resources**. On the URI too like **/doctors/mjones** or  **/slots/1234/appointment**. Collections are for listing resources. Concrete resources are for getting details. \\ Level 1 tackles the question of handling complexity by using divide and conquer, breaking a large service endpoint down into multiple resources.
  
 Request: Request:
Line 113: Line 121:
  
  
-=== 3. Using HTTP Verbs ===+=== 2. Using HTTP Verbs ===
 Characteristics: Characteristics:
   * tunneling a mechanism for an own RPC - remote interaction mechanism. **But to special URIs** - not one service.   * tunneling a mechanism for an own RPC - remote interaction mechanism. **But to special URIs** - not one service.
   * **using Resources**. On the URI too like **/doctors/mjones** or  **/slots/1234/appointment**. Collections are for listing resources. Concrete resources are for getting details.   * **using Resources**. On the URI too like **/doctors/mjones** or  **/slots/1234/appointment**. Collections are for listing resources. Concrete resources are for getting details.
-  * **Using GET, POST, PUT, DELETE, PATCH - similarly to HTTP**. GET is safe. POST, DELETE, PATCH are not.+  * **Using GET, POST, PUT, DELETE, PATCH - similarly to HTTP**. GET is safe. POST, DELETE, PATCH are not. \\ Level 2 introduces a standard set of verbs so that we handle similar situations in the same way, removing unnecessary variation. 
 + 
  
 Request: Request:
Line 156: Line 166:
 </code> </code>
  
 +
 +
 +<code>
 +HTTP/1.1 409 Conflict
 +
 +<openSlotList>
 +  <slot id = "5678" doctor = "mjones" start = "900" end = "1000"/>
 +</openSlotList>
 +</code>
 +
 +
 +
 +
 +=== 3. HATEOAS - Hypermedia As The Engine Of Application State ===
 +
 +Characteristics:
 +  * tunneling a mechanism for an own RPC - remote interaction mechanism. **But to special URIs** - not one service.
 +  * **using Resources**. On the URI too like **/doctors/mjones** or  **/slots/1234/appointment**. Collections are for listing resources. Concrete resources are for getting details.
 +  * **Using GET, POST, PUT, DELETE, PATCH - similarly to HTTP**. GET is safe. POST, DELETE, PATCH are not.
 +  * The **references** to **next steps** are **embedded dynamically** into the response. Allowing to develop the client separately from the server. It allows the server to change its URI scheme without breaking clients. https://ru.wikipedia.org/wiki/HATEOAS \\ Level 3 introduces discoverability, providing a way of making a protocol more self-documenting.
 +
 +Request
 +<code>
 +POST /slots/1234 HTTP/1.1
 +
 +<appointmentRequest>
 +  <patient id = "jsmith"/>
 +</appointmentRequest>
 +</code>
 +
 +Response
 +<code>
 +HTTP/1.1 201 Created
 +Location: http://royalhope.nhs.uk/slots/1234/appointment
 +
 +<appointment>
 +  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
 +  <patient id = "jsmith"/>
 +  <link rel = "/linkrels/appointment/cancel"
 +        uri = "/slots/1234/appointment"/>
 +  <link rel = "/linkrels/appointment/addTest"
 +        uri = "/slots/1234/appointment/tests"/>
 +  <link rel = "self"
 +        uri = "/slots/1234/appointment"/>
 +  <link rel = "/linkrels/appointment/changeTime"
 +        uri = "/doctors/mjones/slots?date=20100104@status=open"/>
 +  <link rel = "/linkrels/appointment/updateContactInfo"
 +        uri = "/patients/jsmith/contactInfo"/>
 +  <link rel = "/linkrels/help"
 +        uri = "/help/appointment"/>
 +</appointment>
 +</code>
 +
 +
 +
 +==== HAL - Hypertext Applicaiton Language ====
 +
 +**REST** is a concept of application architecture. Its multiple maturity states are defined above: Stack of POX, Ressource, Verbs etc.
 +
 +
 +**HATEOAS** is a concept of application architecture. It defines the way in which application clients interact with the server, by navigating hypermedia links they find inside resource models returned by the server.
 +
 +To implement HATEOAS you need some standard way of representing resources, that will contain hypermedia information (links to related resources), for example, something like this:
 +
 +
 +**HAL** is one of such standards. It is a specific format of resource presentation, that can be used to implement HATEOAS.
 +
 +
 +  * HAL Introduction: http://javaeeeee.blogspot.ch/2015/02/introduction-to-hypertext-application.html
 +  * HAL browser: http://api.m.ox.ac.uk/browser/#/
  
 ===== REST API Example ===== ===== REST API Example =====
Line 262: Line 342:
  
 </code> </code>
 +
 +
 +== CURIES ==
 +Cut URI - an approach to reduce the long URLs
 +
 +<code>
 +GET http: //api.ex.com/tales/7dwarfs/1{
 + data{
 + id: 1,
 + type: characters,
 + attributes{
 + name: "oink",
 + size: "1m",
 + race: "dwarf"
 + },
 + curies{
 + {
 + name: "root",
 + href: "http://api.ex.com/v1/"
 + },
 + links{
 + self: "root:tales/7dwarfs/characters/1", 
 + prev: "root:tales/7dwarfs/characters/0", 
 + next: "root:tales/7dwarfs/characters/2", 
 + }
 + }
 +}
 +</code>
 +
rest.1519828818.txt.gz · Last modified: (external edit)