Rest Services
REST Services
Introduction
- REpresentational State Transfer protocol.
- Built around things or resources - Resource based.
- Nouns vs actions. REST services are not action based though HTTP verbs being used to perform different operations on the same resource.
- Resource are identified by a URI.
- Multiple URIs may refer the same resource.
- Client and server communication.
- JSON or XML is used to pass data.
- Lightweight, scalable and maintainable.
● HTTP Verbs
● Constraints
- Uniform interface
- Based on the HTTP specification.
- URIs refers to resources and HTTP verbs are actions performed on resources.
- HTTP verbs (GET, PUT, POST, DELETE).
- URIs (resource).
- HTTP request (header, body, query parameters and URI) and response (header/status and body).
- Use hypermedia to better navigation through resources (HATEOAS - Hypermedia As The Engine Of Application State). Use links for retrieval of related resources.
- Based on the HTTP specification.
- Stateless
- No client state on the server.
- Self containing messages. Each message contains sufficient information for that particular operation.
- Session state will be kept in client side.
- No client state on the server.
- Client-Server
- Use URI to make the connection between two.
- Clearly separates user interface and services. Client is portable, client does not have any connection to data server.Server stand independent from different user interfaces.
- HTTP stack is the communication platform.
- Use URI to make the connection between two.
- Cacheable
- REST services should be cashable.
- Resources returned from the server should be cashable.
- Client can cache resources (implicit caching).
- Server determines what and how should be cached (explicit caching).
- Server-Client negotiate the caching scheme.
- REST services should be cashable.
- Layered System
- Client does not the sees the underlying layers or complexities of the service.
- Client only knows the URI.
- Server is decoupled enough to have multiple layers and intermediate services sitting in between client and server.
- Client only deals with the abstraction of resource URI and verb.
- Highly scalable.
- Client does not the sees the underlying layers or complexities of the service.
● Compliance with REST constraints
- Performance
- Scalability
- Simplicity - Uniform interface
- Modifiability - Change components while running
- Visibility - Communication between agents
- Portability - Components, by moving program code with data
- Reliability
● Best practices
- Nouns over verbs.
- Do not use GET method to alter the state.
- Use plural nouns.
- Represent subresources.
- Use HTTP status codes for errors.
- Use links to other related resource where needed.
- Provide additional functionalities like filtering, pagination, sorting and field selection via query parameters.
- Version the api.
- Always expose via HTTPS.
● HTTP codes
- 200 - OK
- 201 - Created
- 202 - Accepted
- 204 - No content
- 301 - Moved permanently
- 302 - Found
- 304 - Not modified
- 400 - Bad request
- 401 - Unauthorized
- 403 - Forbidden
- 404 - Not found
- 405 - Method not allowed
- 409 - Conflict
- 412 - Precondition failed
- 500 - Internal server error
- 502 - Bad gateway
- 503 - Service unavailable
Comments
Post a Comment