RESTful Web Services

January 20, 2015

REST

REST is an architectural style for web services
- invented by Roy Fielding at UC Irvine
REST is an approach to developing web services that mimics the design of the Web itself
Your service provides access to a linked set of resources.
For each resource, you can perform operations on it similar to the main operations (a.k.a methods) of the HTTP specification.

For each resource, you can typically perform at least one of the following CRUD (Create, Read, Update, Delete) operations:


          GET /api/1.0/users

Retrieve a list of all users.


          GET /api/1.0/users/0

Retrieve the details of User 0.


          POST /api/1.0/users

Create a new user.


          PUT /api/1.0/users/0

Update User 0.


          DELETE /api/1.0/users/0

Delete User 0.


          GET /api/1.0/search?q=tattersail

Perform a search with the query tattersail.

Each operation may produce a result.
- With RESTful services, JSON format is king
POST and PUT methods typically send data
- Also in JSON format
- May be in the URL or in the body of the HTTP Request
  - For GET, the data may appear as query params
Other formats are possible: HTML and XML are typical
If a request needs to be authenticated
- the authentication data appears in HTTP headers

How do you think operations on two resources are handled?


          GET /api/1.0/posts/0/comments/1

Get the first comment on post 0.


          POST /api/1.0/posts/0/comments

Create a new comment on post 0.

While performing an operation on one resource, you reference other resources (by id) in the data that is sent with the request.

Anyone in class have experience with this?

Security: How do you authenticate users?
Identity: How are ids assigned to resources?
Failure: How do we handle failure situations?
- In the example today, I handle it in the JSON
- I could have used HTTP Status Codes (404, 500, etc.)
- Most services will use a combination of both.
Persistence: How are resources stored?