]
Michael Neale commented on ISPN-304:
------------------------------------
What about post either generating a key, or taking a multipart form attachment with the
"name" (file name) as the key and the attachment as the payload? I think that
would make sense as it is creating a child resource with the specified name (true to http
- sec 9.5).
REST API should not use POST
----------------------------
Key: ISPN-304
URL:
https://jira.jboss.org/jira/browse/ISPN-304
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 4.0.0.CR2, 4.0.0.Final
Reporter: Jozef Hartinger
Assignee: Michael Neale
Priority: Optional
Fix For: 4.1.0.ALPHA1, 4.1.0.Final
Currently, the REST API provided by Infinispan uses POST for creating new resources, for
example:
POST to /infinispan/rest/data/foo containing "bar" will create a new key-value
pair (foo, bar)
However, the HTTP spec says that POST should be used for creating *subordinate*
resources, which is not done in this case because the resource itself is created and not a
subordinate one.
Moreover, the RESTful Web Services book which is kind of a bible for writting RESTful
applications claims that the POST method can be used for creating resources *only if the
server is in charge of choosing the URI for a new resource* (for example if a POST sent to
/infinispan/rest/data would cause server to choose a key for the given value and make it
available under /infinispan/rest/data/choosenKey). In contrast, if the *client is
responsible for creating the URI* (which is the case of Infinispan), the client should use
a PUT sent to the chosen URI (PUT /infinispan/rest/data/foo) to create the resource. That
means that there is no difference between the initial creation of a resource and a
subsequent update (both request are PUT requests to the same URI) - fits exactly how
cache.put() works.
The downside of this approach is that the client does not get 409 when he/she wants to
create an explicitly new resource and a resource with that key exists already.
Nevertheless, if this behavior is really needed, it can be achieved alternatively, for
example by introducing a path parameter "overwrite" which if set to
"false" and the resource already exists, will cause the server to return 409.
To summarize, IMHO it would be cleaner to stop using POST for creating new cache records
and use PUT for this purpose instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: