Rest Services

REST Services


Introduction

  • REpresentational State Transfer protocol.
  • Built around things or resources - Resource based.
    1. 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
    1. Based on the HTTP specification.
    2. URIs refers to resources and HTTP verbs are actions performed on resources.
    3. HTTP verbs (GET, PUT, POST, DELETE).
    4. URIs (resource).
    5. HTTP request (header, body, query parameters and URI) and response (header/status and body).
    6. Use hypermedia to better navigation through resources (HATEOAS - Hypermedia As The Engine Of Application State). Use links for retrieval of related resources.

  • Stateless
    1. No client state on the server.
    2. Self containing messages. Each message contains sufficient information for that particular operation.
    3. Session state will be kept in client side.

  • Client-Server
    1. Use URI to make the connection between two.
    2. 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.
    3. HTTP stack is the communication platform.

  • Cacheable
    1. REST services should be cashable.
    2. Resources returned from the server should be cashable.
    3. Client can cache resources (implicit caching).
    4. Server determines what and how should be cached (explicit caching).
    5. Server-Client negotiate the caching scheme.

  • Layered System
    1. Client does not the sees the underlying layers or complexities of the service.
    2. Client only knows the URI.
    3. Server is decoupled enough to have multiple layers and intermediate services sitting in between client and server.
    4. Client only deals with the abstraction of resource URI and verb.
    5. Highly scalable.

● 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

Popular posts from this blog