webr3.org

This post is all about gleaning as much useful information as possible from the HTTP Protocol RFC 2616 in order to answer simple and complex Web of Data related questions.

I've chosen the rather old RFC 2616 (1999!) at this time rather than the upcoming HTTPbis because I feel it's important to know where you are coming from, and whilst many things about the Web of Data feel new, they are really age old principals and technologies which have never been used to their full potential. Further you won't be able to appreciate the refinements in HTTPbis if you don't know what it's refining.

Virtually everything from here on is just a snippet/quote or paraphrase of the RFC. Let's start with a simple one:

Why use HTTP?

HTTP is an application-level protocol for distributed, collaborative, hypermedia information systems. ... HTTP allows an open-ended set of methods and headers that indicate the purpose of a request. ... HTTP is also used as a generic protocol for communication between user agents and proxies/gateways to other Internet systems ... HTTP allows basic hypermedia access to resources available from diverse applications. source

I do fully recommend reading the entire RFC and the new HTTPbis, most questions can be answered by returning to these documents and reading what they say (it's all in the detail); here's some more info gleaned from the RFC:

The difference between POST and PUT, URIs as Identifiers, and URIs to identify more than just documents.

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended .. source

Using POST RESTfully for more than just form data.

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions: Annotation of existing resources; ... Extending a database through an append operation. The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that ... a record is subordinate to a database. source

What to do if something is created as a result of a POST request.

If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header. source

When to use a PUT request?

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. source

How to handle a PUT

If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server.

If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent. source

if extra headers were sent?

Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied to the resource created or modified by the PUT. source

and what if I want to save it somewhere other than the URI specified by the client?

If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response. source

and if the PUT can't be done..

If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. source

can I use PUT with server side versioning?

A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version ... a PUT request on a general URI might result in several other URIs being defined by the origin server. source

how would I let a client know I implement server side versioning when they PUT?

If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent.. source

200 indicates a message body in the response ;)

and DELETE?
well it's short so you may as well read it all..

The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.

A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity. source

note that a response can be 200, meaning you can return a response message (like i have X other versions here [list] or delete them all by clicking here [form input which POSTs to a service] ), or an RDF response that can be interpreted by a client to do the aforementioned :)

but can't I tunnel all actions through GET?

Safe Method .. GET .. SHOULD NOT have the significance of taking an action other than retrieval! source

edit: removed small section about URI vs URL! Do however see the comment from Michael which links to more information on the subject.

Thanks for reading :)
There is much more information in the RFC, but those were some nicer points I found useful and relevant to current Web of Data topics & discussions.