ADN Informatique

Un bon vieux principe élémentaire du web.. un URL c’est supposé être un document.

Du Full REST (et même du rest less) implique donc qu’un URL correspond à 1 document et soit “cachable”.

La nomenclature d’une URL du type

http://”HOST_NAME”/usedcar/fullloadbygeocoordinates?lat=43.345&long=-79.801&dist=250

serait donc fautive.. il faudrait utiliser un format

GET http://…./fullloadbygeocoordinates/43.345,-79.801

pour être plus conforme.

Cependant l’utilisation avec des paramètres pourrait être faite en utilisant préalablement un POST pour créer un document

POST http://”HOST_NAME”/usedcar/fullloadbygeocoordinates?lat=43.345&long=-79.801&dist=250

qui retournerai l’URL d’un nouveau document créé en utilisant les coordonnées en paramètre et par la suite appellé en GET

GET http://….url retourné… ?page=1&encoding=json
Ce nouveau document peut être référé par plusieurs requêtes POST avec plus ou moins de précisions sur les coordonnées, permet de faire varier l’ordre des paramètres, etc.  Ce nouveau document est également référençable et “cachable”.

L’utilisation de l’URL fautive (avec les lon/lat en paramêtre dans la requête GET) devrait au moins retourner une redirection (302) sur un URL correctement forgé avec les coordonnées dans l’URL comme référence au nom du document et non pas en paramètre.

I’m used to be asked “what is REST?”, the answer is simple: “Rest is a development method that involve using HTTP methods to communicate to a web service.”

But when we got into details, digging the web, we found that some details are fuzzy.

The basics, using HTTP verbs GET, POST, PUT and DELETE is agreed by almost averyone. But what does each web is not well defined.

I recently read an article giving an interesting point of view.
GET is used to retrieve information.
POST is used to create or update a document by sending the data to an intermediate URL.
PUT is used to create or completly update a document name by it’s own URL.
DELETE is used to delete a document.

I should agree the detail that POST create a document by sending data to another URL seem right for me. We usally use POST on an URL representing the base of the final one. For example, we POST a “user” to something like http://server/users and that create a new document at an url like http://server/users/TheNewUser. And I also agree that PUT is used on a complete URL like http://server/users/TheUserID. But I disagree with the principle that PUT should always overwrite the document. Following the definition in the HTTP RFC the article is right! But for data consistency, if you allow an external call to define new document URL, you tend to broke the data consistency.

I think that you should only allow document creation by POSTing some data to the root url http://server/users and let the web service define the corresponding ID and URL as http://server/users/NewUserID and after that, allow updating the document using PUT method on it. I also recommand that PUTting or POSTing to the document URL only update part of the document that is sent (as partial form or some blocks) instead of overwriting the entire content. I recommand that to avoid need to first GET the entire document, merge the changes and PUT/POST it back to the server.

On top of that, I strongly recommand using HTTP authentification in the http://user:password@server/service form. You could access the user/pass within your software to extent access rights but your resources are web based protected. The output format should also be negociated using HEADER strings