[
https://jira.jboss.org/jira/browse/ISPN-304?page=com.atlassian.jira.plugi...
]
Jozef Hartinger commented on ISPN-304:
--------------------------------------
Yes, that is exactly what I was thinking. The parameter would have its default value which
means that a user would not need to specify it if he/she is OK with overwriting the value.
On the other hand, if a user wants to explicitly create a new resource (without
overwriting any value), he/she can set the parameter to false to get warned (409) if the
resource exists already.
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
Reporter: Jozef Hartinger
Assignee: Michael Neale
Priority: Optional
Fix For: 4.0.0.CR3
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira