REST API
What is REST?
REST is acronym for REpresentational State Transfer. It is architectural style for distributed hypermedia systems
Like any other architectural style, REST also does have it’s own 6 guiding constraints which must be satisfied if an interface needs to be referred as RESTful.
These principles are listed below.
* Guiding Principles of REST:
Client–server – By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple
platforms and improve scalability by simplifying the server components.
Stateless – Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any
stored context on the server. Session state is therefore kept entirely on the client.
Cacheable – Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable.
If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests.
Uniform interface – By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified
and the visibility of interactions is improved. In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior
of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
Layered system – The layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component
cannot “see” beyond the immediate layer with which they are interacting.
Code on demand (optional) – REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts.
This simplifies clients by reducing the number of features required to be pre-implemented.
* Architectural Constraints :
REST defines 6 architectural constraints which make any web service – a true RESTful API.
Uniform interface
Client–server
Stateless
Cacheable
Layered system
Code on demand (optional)
* 200(OK):
HTTP Status 200 (OK)
The HTTP Status 200 (OK) status code indicates that the request has been processed successfully on server. The response payload depends on
HTTP method which was selected for request.
HTTP Status 200 – Response Payload
HTTP METHOD RESPONSE PAYLOAD
GET An entity corresponding to the requested resource is sent in the response.
HEAD Response has only HTTP header fields and no payload is sent in response.
POST Response generally contain information about progress status representation or result of action that was performed in request.
PUT Progress status representation of request is sent in response.
DELETE Progress status representation of request is sent in response.
OPTIONS:
A list of valid request methods associated with the resource using Allow header. e.g.
Allow: HEAD, GET, OPTIONS
Content-Length: 18
Content-Type: text/plain;charset=UTF-8
Date: Thu, 06 Apr 2020 16:51 EST
Server: Apache-Coyote/1.1
TRACE A representation of the request message as received by the end server.
* HTTP Status:
1×× Informational
100 Continue
101 Switching Protocols
102 Processing
2×× Success
200 OK
201 Created
202 Accepted
203 Non-authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
208 Already Reported
226 IM Used
3×× Redirection
300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
307 Temporary Redirect
308 Permanent Redirect
4×× Client Error
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
418 I’m a teapot
421 Misdirected Request
422 Unprocessable Entity
423 Locked
424 Failed Dependency
426 Upgrade Required
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
444 Connection Closed Without Response
451 Unavailable For Legal Reasons
499 Client Closed Request
5×× Server Error
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage
508 Loop Detected
510 Not Extended
511 Network Authentication Required
599 Network Connect Timeout Error
What is REST?
REST is acronym for REpresentational State Transfer. It is architectural style for distributed hypermedia systems
Like any other architectural style, REST also does have it’s own 6 guiding constraints which must be satisfied if an interface needs to be referred as RESTful.
These principles are listed below.
* Guiding Principles of REST:
Client–server – By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple
platforms and improve scalability by simplifying the server components.
Stateless – Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any
stored context on the server. Session state is therefore kept entirely on the client.
Cacheable – Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable.
If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests.
Uniform interface – By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified
and the visibility of interactions is improved. In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior
of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
Layered system – The layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component
cannot “see” beyond the immediate layer with which they are interacting.
Code on demand (optional) – REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts.
This simplifies clients by reducing the number of features required to be pre-implemented.
* Architectural Constraints :
REST defines 6 architectural constraints which make any web service – a true RESTful API.
Uniform interface
Client–server
Stateless
Cacheable
Layered system
Code on demand (optional)
* 200(OK):
HTTP Status 200 (OK)
The HTTP Status 200 (OK) status code indicates that the request has been processed successfully on server. The response payload depends on
HTTP method which was selected for request.
HTTP Status 200 – Response Payload
HTTP METHOD RESPONSE PAYLOAD
GET An entity corresponding to the requested resource is sent in the response.
HEAD Response has only HTTP header fields and no payload is sent in response.
POST Response generally contain information about progress status representation or result of action that was performed in request.
PUT Progress status representation of request is sent in response.
DELETE Progress status representation of request is sent in response.
OPTIONS:
A list of valid request methods associated with the resource using Allow header. e.g.
Allow: HEAD, GET, OPTIONS
Content-Length: 18
Content-Type: text/plain;charset=UTF-8
Date: Thu, 06 Apr 2020 16:51 EST
Server: Apache-Coyote/1.1
TRACE A representation of the request message as received by the end server.
* HTTP Status:
1×× Informational
100 Continue
101 Switching Protocols
102 Processing
2×× Success
200 OK
201 Created
202 Accepted
203 Non-authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
208 Already Reported
226 IM Used
3×× Redirection
300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
307 Temporary Redirect
308 Permanent Redirect
4×× Client Error
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
418 I’m a teapot
421 Misdirected Request
422 Unprocessable Entity
423 Locked
424 Failed Dependency
426 Upgrade Required
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
444 Connection Closed Without Response
451 Unavailable For Legal Reasons
499 Client Closed Request
5×× Server Error
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage
508 Loop Detected
510 Not Extended
511 Network Authentication Required
599 Network Connect Timeout Error
