HTTP HEAD and OPTIONS

There are 2 other HTTP methods which are a part of a URI:

- HEAD: Retrieve a metadata-only representation
- OPTIONS: Check which HTTP methods a particular resource supports

HEAD:
- making a call to a resource to fetch metadata without downloading an entire collection
- a client can use HEAD to check if a resource exists, to find out other information about the resource without fetching it's entire representation. So we have the same functionality like a HTTP GET but now the call does not fetch data.

OPTIONS:
- The OPTIONS method lets the client to discover what it's allowed to do to a resource. The response to an OPTIONS request contains the HTTP Allow header, which lays out the subset of the uniform interface this resource supports.

E.g. : Allow: GET, HEAD

That means that the client can send a GET and HEAD request to this resource but the resource does not support any other methods - effectively, this resource is read-only.

Normal RESOURCE:


Advanced RESOURCE:

PUT vs. POST Creation Paradigm

To create a new “thing” shall I use PUT or POST?

There is a clear answer for this question:

- If the client is responsible for creating the ID of the “thing” use a PUT
E.g: “./users/roni” <- roni is unique and given by the client -this is a new URI!

- If the server is responsible for creating the ID of the “thing” use a POST
E.g. “./users/” and as a post key/value the client transfers username=roni and prob. to id would be an auto generated number.

The “thing” retrieval pattern

use GET and not POST

Why not POST?
–Overloaded POST: the not-so-RESTful pattern

–It’s overloaded because a single HTTP method is being used to signify any number of non-HTTP methods.

–By using POST it will happen very easy that we implement an RPC service. In a RPC service we are using post and the Action is one of it’s parameters: ”/orders?action=delete&id=13” That’s not REST!

it's as easy as that

GET vs. POST Retrieving Paradigm

To retrieve a “thing” from a Resource we have 2 options:

–The HTTP GET options:
•GET ./order/221
•GET ./order?id=221

–The HTTP POST option:
•POST /order
–id = 221 [key value] … add as much as you need!

RESTful from a conceptional view - Part 1

REST (Representational State Transfer) for 1 slide:

• Web Services expose their data and functionality through resources identified by a unique URI
• Uniform Interface Principle: Clients interact with resources through a fix set of verbs
  Example:
  - GET – read
  - PUT – update
  - DELETE – remove
  - POST – create
• Multiple representations for the same resource
• Hyperlinks model resource relationships and valid transfer state transitions for dynamic protocol description and discovery