[ https://jira.jboss.org/jira/browse/ISPN-304?page=com.atlassian.jira.plugi... ] Jozef Hartinger updated ISPN-304: --------------------------------- Description: 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. was: 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 tries to overwrite an existing value. 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

[ 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. -- 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

[ https://jira.jboss.org/jira/browse/ISPN-304?page=com.atlassian.jira.plugi... ] Manik Surtani updated ISPN-304: ------------------------------- Fix Version/s: 4.1.0.BETA1 4.1.0.GA (was: 4.0.0.GA) Affects Version/s: 4.0.0.GA -- 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

[ https://jira.jboss.org/jira/browse/ISPN-304?page=com.atlassian.jira.plugi... ] 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 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html - sec 9.5). -- 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

[ https://jira.jboss.org/jira/browse/ISPN-304?page=com.atlassian.jira.plugi... ] Manik Surtani commented on ISPN-304: ------------------------------------ Is this not a discussion for reststar-caching? http://groups.google.com/group/reststar-caching There are others on that list who may not have visibility of this JIRA. -- 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

[ https://jira.jboss.org/jira/browse/ISPN-304?page=com.atlassian.jira.plugi... ] Manik Surtani commented on ISPN-304: ------------------------------------ I am able to post - http://groups.google.com/group/reststar-caching/browse_thread/thread/57d0... Perhaps you didn't post as michael.neale(a)gmail.com (which is what you are registered on the list as)? -- 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

[ https://jira.jboss.org/jira/browse/ISPN-304?page=com.atlassian.jira.plugi... ] Michael Neale closed ISPN-304. ------------------------------ Resolution: Won't Fix Closing for now until there is more discussion on reststar cachine etc... for now, perhaps discourage people from using POST - use PUT so semantics are identical to what you would expect a cache to be (temp workaround). Would also like to hear from Greg Luck re his thoughts and ehcache etc. -- 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