PUT/POST for new cache entry?

[Michael Neale]

This may be more a question of "teach michael about REST" as I am rest-
cluefree (more attacking it from a user angle).

So in Inifinispan and ehcache servers, data is put in via a POST. With
Infinispan I thought I would be clever and use POST for creating new
items, and PUT for updating (POST would fail if it was on an existing
key) as I found that useful (but I am wierd).

However, as people have rightly pointed out (ref
https://jira.jboss.org/jira/browse/ISPN-304), POST is really for
creating subordinate resources of an existing resource, not specifying
the name of the resource.

It has been suggested if we want to allow client specified names we
use PUT instead.

..and if a POST is done to a resource, then the server should generate
a key for it, and return it (which is actually a useful thing if I
client just wants to stash things away).



Thoughts? precedents?

[Bill Burke]

I think you need to think in terms of links and media types. Hypermedia
is a key principle of REST.

What you should be doing is defining a link for updating cache entries
and a different link for creating cache entries. Whether or not these
things are the same URL or not is irrelevant. URL schemes are an
implementation detail.

The defined semantics for the link defines how you interact with the
resource. At least, that's how I understand it. The link header
specification gives you a way to publish links without having to parse a
media type.

Hope that helps.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Michael Neale]

right - but how does this deal when the user wants to specify the
key?
so you hit up /cacheName (cause the root told you to),
and it has a link to the various places you can put things? (PUT) ?

(you are talking HATEOAS here I think?).

[Bill Burke]

You can use link templates too. The description of the link would say
that it is a template and that you must provide one or more variables to
complete the URI. I guess the idea is to make URLs as opaque as
possible so that they can be redesigned easily (or even changed on the fly).