DELETE
On successful deletion, return HTTP status 200 (OK) along with a response body.
Calling DELETE on a resource a second time will often return a 404 (NOT FOUND) since it was already removed and therefore is no longer findable.
Generally exposing Delete method in REST is not a good practice because it can lead to delete the information.
SHOULD DELETES BE IDEMPOTENT?(unchanged when multiplied by itself)
Yes, if possible. Usually, you’d mark resources as deleted in the database and not actually delete them. That way if a client requests an already deleted object, you ignore it. This is a better user experience than throwing an error.
If using PUT for create, return HTTP status 201 on successful creation
Do not expose unsafe operations via GET—it should never modify any resources on the server.
GOOD READ FOR REST API
http://www.restapitutorial.com/lessons/httpmethods.html
http://www.infoq.com/articles/rest-introduction
ST" in "REST" stands for "State Transfer", and indeed, in a good REST design operations are self-contained, and each request carries with it (transfers) all the information (state) that the server needs in order to complete it.
Your REST resource is the ticket. Use GETs to read the ticket, PUT to modify the ticket state, and DELETE to do a logical delete (cancellation). setting a flag stating that the record is deleted) as opposed to actually or physically deleting the record
the things — the resources — that merit being identified with a URI are far more abstract than a database entry.
the five key principles are:
Give every “thing” an ID
Link things together
Use standard methods
Resources with multiple representations
Communicate statelessly
To summarize the first principle: Use URIs to identify everything that merits being identifiable, specifically,
http://example.com/orders/2007/11
http://example.com/products?color=green
At first, these appear to be something different — after all, they are not identifying a thing, but a collection of things (assuming the first URI identifies all orders submitted in November 2007, and the second one the set of green products). But these collections are actually things — resources — themselves, and they definitely merit identification.
Idempotence is also guaranteed for PUT (which basically means “update this resource with this data, or create it at this URI if it’s not there already”)
POST is not idempotent
POST, which usually means “create a new resource”, can also be used to invoke arbitrary processing and thus is neither safe nor idempotent.
//Very Important By stateless it means that the web server does not store any state about the client. The session is stored on the client. The server is stateless.
That does not preclude other services that the web server talks to from maintain state about business objects, just not about the clients connection state.
The clients application state should never be stored on the server, but passed around from the client to every place that needs it.
//Very ImportantThat is where the ST in REST comes from, State Transfer. You transfer the state around instead of having the server store it. This is the only way to scale to millions of users.
OPTIONS method returns info about API (methods/content type)
HEAD method returns info about resource (version/length/type)
Server response
OPTIONS
HTTP/1.1 200 OK
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:24:43 GMT
Content-Length: 0
HEAD
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:12:29 GMT
ETag: "780602-4f6-4db31b2978ec0"
Last-Modified: Thu, 25 Apr 2013 16:13:23 GMT
Content-Length: 1270
OPTIONS Identifying which HTTP methods a resource supports, e.g. can we DELETE it or update it via a PUT?
HEAD Checking whether a resource has changed. This is useful when maintaining a cached version of a resource
HEAD Retrieving metadata about the resource, e.g. its media type or its size, before making a possibly costly retrieval
No comments:
Post a Comment