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.