Re: [Pki-devel] TPS REST interface design
On Mon, 2013-07-01 at 12:30 -0500, Endi Sukma Dewata wrote:
On 7/1/2013 11:51 AM, Endi Sukma Dewata wrote:
> From http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5:
>> 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;
>> - Posting a message to a bulletin board, newsgroup, mailing list,
>> or similar group of articles;
>> - Providing a block of data, such as the result of submitting a
>> form, to a data-handling process;
>> - 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 file is subordinate
>> to a directory containing it, a news article is subordinate to a
>> newsgroup to which it is posted, or a record is subordinate to a
>> database.
>
> Adding a new user or profile into a collection would be analogous to the
> above examples.
Just to clarify, when adding a file into a directory we know the file
name already. Still, this is given as an example of a POST operation.
So, knowing the ID ahead of time is irrelevant to picking PUT vs. POST
to create a resource.
Just to be clear, it is perfectly RESTful to create an interface using
only GET and POST. POST can literally be used for pretty much anything
and still be restful. The question is more one of restful practice.
Its far more intuitive and friendly to use the other verbs PUT and
DELETE, even though there may be some clients that do not support these
operations.
As to this specific use of PUT vs. GET, I've seen best practice
guidelines that advocate both scenarios. I am, however, most convinced
by the idea that the POST allows the server more flexibility in
selecting the Location.
An example I saw of using PUT was for a user being able to store their
personal set of favorites. For this case, it is entirely appropriate
that the user controls the location URL.
In our case, what we are creating are server resources and we want
control over that.
So, point conceded.