WHY DOES EVERYONE NEED REST – ???

REST – Representational State Transfer

 —- It is an Architectural Style and not a Standard

Prologue

  • Everything is considered as Resource.
  • Every Resource is identified by URI
  • Stateless – Every Request/Response should contain enough information for exchanging data.
  • Message format – XML, JSON, Custom format
  • It is based on HTTP
  • SImple HTTP is used for communication between machines.
  • Uses HTTP methods ( GET, POST, PUT, DELETE, HEAD) for all CRUD operations
  • Lightweight
  • Platform Independent ( Server – Unix, Client -Windows)
  • Language independent ( Server – C# , Client – Java)
  • Can be used in presence of firewall
  • HTTP Accept  headers no accepted should return 406 response
  • OPTIONS – Use  this to know which HTTP methods are supported by a resource
  • PATCH – used for updating only partial resource
  • 4XX error code – convey some error happened on the client side. It should not send the same request again
  • 5XX error code –  Issue is on the server side. Example DB is down or etc. Example client is sending a request to add a record in the DB. In this case Client can send the same request

Does Not Offer

  • built – in Security  features – Can use username/tokens for security along with the webservice
  • Encryption  – Can be on top of  HTTPS
  • Session Management
  • QOS

Why Rest ?

  1. Scalability – Large no of interconnected machine able to communicate seamlessly
  2. Generality – Based on HTTP standard.
  3. Independent – Client server are independent and are loosely coupled.
  4. Latency/Caching
  5. Security – Follow HTTP specification
  6. Encapsulation
  7. HATEOAS – Hypermedia As The Engine Of Application State

6 Constraints in REST

Uniform Interface

  • All resources are identified using URI/URLS
  • Resources are different from representation(JSON,XML etc)
  • Clients can manipulate the resources

Stateless

  • Client and Server cannot persist any context about the other. The request/response should contain all required information as part of header, URL etc

Cachable

  • Client can cache the response.
  • Response can decide if it can be persisted on the client side

Client-Server

  • They are loosely coupled.

Layered System

  • At any point of time client cannot say if it is connected to end server or intermediate server as real URLS should not be used.

Resource

  • Nouns and not verbs.
  • Coarse Grained and not Fine Grained
  • Examples
    • Coarse Grained – UserService.setUserDetails(userObj)
    • Fine Frained – UserService.setUID(String uid), UserService.setUserName(String userName)
  • 2 types
    • Collection – ../applications —> returns all the applications
    • Instance – ../applications/abcxyz – returns only the specific app ( abcxyz)

Behavior

  • IDEMPOTENT – Always return the same server state for every request.
    • GET – Used for READ
    • PUT – Used for create/update. Should always send complete data of the resource for create/update as it is idempotent
    • DELETE
    • HEAD – headers, no body
  • NON-IDEMPOTENT
    • POST – Used for create/update.  Can send partial data while creation. Later can use partial data for update as it is not idempotent

Media Types

It is the content type of the request and response. Format Specification + Parsing type

Request:  Specifies “Accept”  with type in the header

Response: content-type: application/json, application/foo+json;application etc


How are rest APi’s accessed

Should design to return the same data format across various REST clients

  1. Browser –  Calling a REST API if it returns JSON resource.
  2. Rest Client – Return same JSON resource here as well

Versioning

Versioning can be done through 2 ways

  • URL Versioning
  • Media-type
    • Set the version in the content-type as application/foo+json;application&v=1
    • Can use any no.of version as the URI will remain unchanged
    • Client can choose when they want to upgrade to new version
    • Best practice, but not used widely

Camel Case

Always use camel case in JSON as it is based on Javascript convention

Use myArray.forEach and not myArray.for_each

Date/Time – Use ISO 8610 – UTC

Linking

  • Resources can access other resources using HREF in REST
  • XML uses XLINK
  • Example : Employee resource would like to display the Department details.  In this case Employee JSON can have a HREF to Department Resource URI

ResourceExtension 

When header is not supported – resource extensions can be used as follows

/application/abcyz.json , /application/abcyz.csv  .  This overrides the Accept header.


Best practices

Authentication in REST

  • HTTP Auth
    • UserName/Password is prompted when the user request for the rest api. The browser caches the credentials and sends it along every request
    • Disadvantage
      • Password should be sent with every request
      • No prevention from tampering the header or body
  • HMAC – Hash based message authentication
    • Password is hashed along with more information like timestamp etc
    • Prevents eavesdropping and replay attacks.
  • Login Service like OAuth
    • Accept credential and generate the tokens.
    • Token will be included as part of URL param as &authToken=XYZ
    • Tokens can be created with expiration date.
  • Cookies
    • Should not be used as it violates the “Stateless” feature of REST

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Cheat Sheet To JAVA Latest Technology

%d bloggers like this: