BookNote RESTful Web Service - soasme/soasme.github.com GitHub Wiki

  • Web Inhabitants
  • HTTP
  • HTTP Request
  • HTTP verb(or action): standardized. GET POST PUT PATCH DELETE. GET(retrieve data), DELETE(delete data), PUT(overwrite it with difference data).
  • URI: path
  • Headers: applications can define their own.
  • Entity body: GET has no entity body, all information are in headers and uri.
  • HTTP Response
  • Response Code: 200, 404, ...
  • Response Header
  • Entity body: media type is depended on header Content-Type.

  • The Competing Architectures

  • RESTful resource-oriented * scoping information goes into URI * method match method information.

  • RPC-style

  • REST-RPC hybrid. * MOST WEB APPLICATIONS, -w-

  • Client...

  • Different...

  • The Resource-Oriented Architecture

  • REST is just a set of design criteria.The phrases “resource-oriented” and “resource-oriented architecture” have been used to describe RESTful architectures in general.
  • What is Resource?
  • store on computer.
  • represented as a stream of bits.
  • URI.
  • name and address of a resource
  • Addressability
  • Statelessness
  • Every request happens in complete isolation.
  • Representations
  • some data about the current state of a resource.
  • Deciding Between Representations
  • Use a distinct URI(such as appending suffix) to proffer multiple representations.
  • Use self-defined HTTP request header to get specified kind of representations.
  • Recommend: put as much information as possible in the URI and as little as possible in the request metadata: cause' metadata almost always get lost in transition.

  • Uniform Interface

  • GET PUT DELETE

  • HEAD * retrieve a metadata-only representation. * Fetch metadata about a resource WITHOUT downloading the possibly enormous entity-body.

  • OPTIONS: * check which HTTP methods a particular resource supports. * Response contains HTTP Allow header like: Allow: GET, HEAD. * Request without Authorization * SO FAR, OPTIONS IS A PROMISING IDEA THAT NOBODY USES.

  • POST * RFC2616 definition of POST in HTTP standard. * Creating SUBORDINATE resources. + The difference between PUT and POST

    • the client uses PUT when it’s in charge of deciding which URI the new resource should have.
    • The client uses POST when the server is in charge of deciding which URI the new resource should have. + POST(a) vs POST℗

  • Safety and Idempotent

    • safe: GET HEAD
    • idempotent: GET HEAD OPTIONS PUT DELETE
    • network is not reliable.
    • GET /xxx/delete will be a disaster.

  • Read-Only Services

  • Figure out dataset and split to resources.

  • Naming Resources.

  • Hierarchy? Path variables
  • No Hierarchy? Use Commas or Semicolons
  • Algorithmic Resource? Use Query Variables
  • Your own URI recap
  • Design Representations
  • Response
  • Return readable status code when going wrong.
  • two response headers (Last-Modified and ETag), and two request headers (If- Modified-Since and If-None-Match)

  • Read-Write Services

  • An Implementation

  • Best Practices

  • Building Blocks

  • Compare against other Services

  • Ajax Applications

  • Frameworks

  • Appendix