REST

• REpresentational State Transfer
• Proposed by Roy Fielding in 2000
• Description of design principles for an API
• Built & designed around HTTP
• How a "well-designed" web service should behave

REST

• Six architectural constraints:
  • Client-Server Architecture
  • Statelessness *
  • Cacheability
  • Layered
  • Code Mobility
  • Uniform Interface *
    • Resource Identification *
    • Hypertext-driven (HATEOAS) *
• Uses HTTP methods (GET, POST, PUT, PATCH, DELETE)

REST - Benefits

• Consistent / Uniform
• Portable
• Semantic
• Easy to reason about

REST - Problems

• Often poorly understood or executed
• Incorrectly or incompletely implemented
• In order to be RESTful, a service must comply with ALL architectural constraints
  • Many do not

REST - Problems

• Often poorly understood or executed
• Incorrectly or incompletely implemented
• In order to be RESTful, a service must comply with ALL architectural constraints
  • Many do not

REST - Problems

• Often poorly understood or executed
• Incorrectly or incompletely implemented
• In order to be RESTful, a service must comply with ALL architectural constraints
  • Many do not
• Very real day-to-day problem in web systems development
• Why I chose this paper

REST - Problems

Formalizing REST - CSP

• The authors use CSP to formalize a model for REST
  • First described by Hoare
  • Expressive way to model concurrent and sequential communication between processes over channels
  • Syntax:
    • Define behavior, read messages, write messages, concurrency, synchronization

Formalizing REST - Model

• Model REST using three processes: Client, Server and Resource
• Communication channels between Client/Server, Server/Resource

Formalizing REST - Model

Formalizing REST - Model

Formalizing REST - Model

Formalizing REST - Model

• This is a good model, for the most part
  • Very succinct, minimal
  • Maps well to real-world implementation
  • For the most part, describes the properties they aim to prove well

Formalizing REST - Verification

• Authors choose to verify:
  • REST Behavior
    • Statelessness
    • HATEOAS
  • HTTP Methods
    • Safety (GET)
    • Idempotence (GET, PUT, DELETE)
• Why?
  • "Most Important"
  • "Most Confusing"
  • ???

Formalizing REST - Verification

• Authors choose to verify:
  • REST Behavior
    • Statelessness
    • HATEOAS
  • HTTP Methods
    • Safety (GET)
    • Idempotence (GET, PUT, DELETE)

Formalizing REST - Verification

• Use first-order logic to define failure cases and tests to (attempt to) formally define these properties
• Then use PAT (Process Analysis Toolkit) to verify properties
  • Automated model checker
  • Seems nice, but they don't include all the code
    • Angry reacts only

Formalizing REST - Verification

Statelessness

HATEOAS

Formalizing REST - Verification

Method Safety

Method Idempotence