Please enable JavaScript.
Coggle requires JavaScript to display documents.
REST API: Video 3-9 (Video 5: HTTP Methods now let's focus on…
REST API: Video 3-9
Video 5: HTTP Methods
- now let's focus on operations that can be performed using our URIs and data that can be exchanged
Different HTTP methods for different operations: GET, POST, PUT, DELETE, HEAD, OPTIONS
- for example action based look like this /getMessage.do?id=1 however we don't want such uri
- has 3 piece of info, refers to message, id, and gets
- Now our url has /message/10,refers to message and id but doesnt have get. that's why we use GET
- if uri is postMessage.do?id=10, we use POST
-
-
-
creating a new message; no message id yet
uri for creating is always issued to colection uri: /messages
POST /messages
you should provide body as content of your new resource, one resource created, response will be new id
-
Video 4: Collection URIs
- RESTful URIs belong to 2 types:
- 1: Instance Resource URIs : identifies specific instance of resource using its id. e.g message with id 1,etc singular
- Collection Resource URIs: /messages/2/comments = to collection of resources. such url will return all comments that's why called collection, it's plural
- /messages returns all messages
-/profiles returns all profiles
- As a result this is another advantage of nesting
there is a tradeoff
- what if you wanna get all comments regardless of message ids
- depends on your client; no right or wrong; you decide
Filtering Result: make use of parameters
- a way for client to paginate or filter results
- pagination: starting point and ending
- /messages?offset=30&limit=10
- the above url fetches(gets) all messages starting from number 30 and end returns next 10 messages
- Other examples: /messages?year=2014
Video 9 The Richardson Maturity Model
Is this API fully RESTful ?
We know if it's fully restful by following the model and breaks all concepts we discussed so far into 3 levels
Level 0 (this more for SOAP not RESTful remember)
- one URI (this url receives all the requests)
- request body contains all the details such as how does it know what to do, what operation to perform etc
- called Swamp of Plain old xml (everything defined in xml)
Level 1 Resource URI (RESTful)
- individual URI for each resource
Level 2: HTTP methods
- introduce different https methods for different resource URIs
- Use the right Http methods, status codes
Level 3: Implement HATEOAS
- responses have links client can use further to make more request
VIDEO 7 RESPONSE
what should server respond to client request
in web application, response would have been html, css. no styling and formatting for RESTful, you just need to send the actual data.
XML/JSON format
-makes easy for JS client to convert into object
-e.g request to /messages/1 returns data in JSON format:
- {"id":1, "message":"Hello World"}
- In XML, same response would look smth like this:
<messageEntity>
<id>10</id>
<message>Hello</message>
</messageEntity>
- these two responses are different representation of the same resource
How does server know which format to send?
- content-type in http header
Status Codes: send right error code to your client
- 200 OK
- 404 Not Found
- 1xx informational
- 2xx success codes
- 3xx redirection (ask client to send request somewhere else)
- 4xx client Error (client making error)
- 5xx Server error
- Look up status codes for CRUD operations
-
VIDEO 8 HATEOAS
hypermedia as the engine of application state
- way to provide links to resources in API response
- no formal documentation for services
- in response include URI of shares, likes, for the message similar to hyperlinks
- then client developer could make subsequent call to those URIs that's why hypermedia is engine of application state
- insert href in response for every resource to itself
the 'rel' attribute
- specify relationship between current document
and link document
- <link rel="stylesheet" href="https://boot.css">
- {
"links": [ {href: "/messages/1"
"rel": "self"}
]
}
- self means pointing to itself
- certain specific values that are allowed for rel
Overview of our Messenger Application
- Lets people post messages as status update
- Write comments to other messages
- like or share other messages
- User Profiles
Resource based URIs for Profile
- /profile/sher.html
- /profile/sher
- /profile/{username}
URI for Messages
- /messages/{messageID}
- /messages/1
URI contains Nouns not Verbs
-profiles, things in the system, messages etc are resources which are called by client
- resource names are plural
- advantage: they are not dependent on framework such as /action.do?id=1;
Resource Relations
- resources are dependent on other resources
- For example, messages and comments are related. Someone post message and someone comments on it. One to many relationship
- Url for comments could be /comments/{commentId} but it shows no relationship to message it refers to
- Better URL is /messages/{messageId}/comments/{commentID}
- The above url makes it very clear that comment belongs to a particular message
- URL for message likes: /messages/{messageId}/likes/{likeID}
- URL for share:
/messages/{messageId}/shares/{shareID}
- The above urls is for 1 to many relationship. How about 1 to 1 or many to many
-