Software Development - Web Programming

• Scalability
• Generality
• Independence (language independent)
• Latency (Caching)
• Security (built into HTTP)
• Encapsulation (decoupling)

Designing a Beautiful REST + JSON API (another talk)

Beautiful REST + JSON APIs

In an earlier post by Ben Schmaus, we shared the principles behind our circuit-breaker implementation. In that post, Ben discusses how the Netflix API interacts with dozens of systems in our service-oriented architecture, which makes the API inherently more vulnerable to any system failures or latencies underneath it in the stack. The rest of this post provides a more technical deep-dive into how our API and other systems isolate failure, shed load and remain resilient to failures.

1. Client-server
2. Stateless server
3. Cache
4. Uniform interface
   • Identification of resources
   • Manipulation of resources through representations
   • Self-descriptive message
   • Hypermedia as the engine of application state (HATEOAOS)
5. Layerd System
6. Code-On-Demand

1. Componentization via services
2. Organized around business capbilities
3. Products not Projects
4. Smart endpoints and dumb pipes
5. Decentralized Governance
6. Decentralized Data Management
7. Infrastructure Automation
8. Design for failure
9. Evolutionary Design

Very good intro to REST

REpresentational State Transfer

• An architectural style for designing distributed systems
• Not a standard, but rather a set of constraints
• Not tied to HTTP, but associated most commonly with it

• URI's identify resources
• HTTP verbs describe a limited set of operations that can be used to manipulate a resource
  1. GET
  2. DELETE
  3. PUT
  4. POST
• Headers help describe the messages

GET

• Retrieve Information
• Must be safe and idempotent - can have side effects, but since the user doesn't expect them they shouldn't be critical to the operation of the system.
• GET can be conditional or partial
  • If-Modified-Since
  • Range
• Example: GET /games/1

DELETE

• Request that a resource be removed
• The resource doesn't have to be removed immediately
• Removal may be a long running task
• Example: DELETE /games/1

PUT

• Requests that the entity passed by stored at the URI
• Can be used to create a new entity or modify an existing one, however, creation is uncommon as it allows the client to select the id of the new entity.
• Example: PUT /games/1/doors/2
  
• Put doesn't have to replace everything, it can be partial. { "status":"SELECTED" }

POST

• Requests that the resource at a URI do something with the enclosed entity
• What that something is could be almost anything
  • Create
  • Modify
• The major difference between POST and PUT are what resource the request URI identifies.
• Example: POST /games

Example of creating a game with REST

Create a Game

• Well-known entry point
• Doesn't require any input other than requesting that a game be created
• Needs to return us a URI of the newly created game
• Example: POST /games (creates a game)

List the current state of all Doors

• Needs to return us a collection that represents the state of all doors in the game.
• Design doesn't have 'Door1', 'Door2', 'Door3', just three doors
• Example: GET /games/0/doors
  [{"status": "CLOSED"}, {...},{,,,}]

Select a Door

• There is no HTTP verb "SELECT", so how do we represent the selection of a door?
• Request a resource mutation that leaves the resource in desired state.
• Example: PUT /games/1/doors/2
  {"status": "SELECTED"}

Open a Door

• Like select, we want to request a mutation to the desired state
• Since the same (or same type of) resource is being modified, we re-use the same payload.
• Example: /games/1/doors/3
  {"status": :"OPEN"}

List the final state of the Game

• Needs to return an object that represents the state of the game
• Example: GET /games/0
  {"status": "WON"}

Destroy the Game

• No input required
• No output required
• Example: DELETE /games/0

Status Codes

Broad Categories

• 1XX: Informational
• 2XX: Success
• 3XX: Redirection
• 4XX: Client Error
• 5XX: Server Error

Success Status Codes (2XX)

• 200 OK
  
  • Everything worked
• 201 Created
  
  • The server has successfully created a new resource
  • Newly created resource's location returned in the Location header
• 202 Accepted
  
  • The Server has accepted the request, but it is not yet complete
  • A location to determine the request's current status can be returned in the Location header

Client Error Status Codes (4XX)

• 400 Bad Request
  • Malformed Syntax
  • Should not be repeated without modification
• 401 Unauthorized
  • Authentication is required
  • Includes a WWW-Authenticate header
• 403 Forbidden
  • Server has understood, but refuses to honor the request
  • Should not be repeated without modification
• 404 Not Found
  • The server cannot find a resource matching a URI
• 406 Not Acceptable
  • The server can only return response entities that do not match the client's Accept header
• 409 Conflict
  • The resource is in a state that is in conflict with the request
  • Client should attempt to rectify the conflict and then resubmit the request

Architectural Styles and the Design of Network-based Software Architectures