You are correct, but this bug is 'fixed' by another bug a few lines up:
private static final Set<String> CREATE_SYNONYMS =
Sets.newHashSet("put", "create");
private static final Set<String> UPDATE_SYNONYMS =
Sets.newHashSet("post", "update");
that should actually be
private static final Set<String> CREATE_SYNONYMS =
Sets.newHashSet("post", "create");
private static final Set<String> UPDATE_SYNONYMS =
Sets.newHashSet("put", "update");
and UPDATE_SYNONYMS and CREATE_SYNONYMS swapped. See SHINDIG-842.
Thanks for spotting.
Ciao
Henning
On Sun, Jan 11, 2009 at 22:01, Shishir Birmiwal <[email protected]> wrote:
> Dear shindig-dev,
>
> I have a query about a snippet of code in DataRequestHandler. Apparently, it
> invokes PUT for create and POST for update. Also, RPC create / update get
> mapped to PUT / POST respectively. This should really be the other way. As
> per the RESTful spec, POST -> create new and PUT -> update in place.
>
> Is this a bug, or is this something that I am missing?
>
> Thanks,
> Shishir
>
> ..
> private static final Set<String> GET_SYNONYMS = Sets.newHashSet("get");
> private static final Set<String> *CREATE_SYNONYMS* = Sets.newHashSet("*put
> *", "*create*");
> private static final Set<String> *UPDATE_SYNONYMS* = Sets.newHashSet("*
> post*", "*update*");
> private static final Set<String> DELETE_SYNONYMS =
> Sets.newHashSet("delete");
>
> public Future<?> handleItem(RequestItem request) {
> if (request.getOperation() == null) {
> return ImmediateFuture.errorInstance(new
> SocialSpiException(ResponseError.NOT_IMPLEMENTED,
> "Unserviced operation"));
> }
> String operation = request.getOperation().toLowerCase();
> Future<?> responseItem;
> try {
> if (GET_SYNONYMS.contains(operation)) {
> responseItem = handleGet(request);
> } else if (UPDATE_SYNONYMS.contains(operation)) {
> responseItem = *handlePost*(request);
> } else if (CREATE_SYNONYMS.contains(operation)) {
> responseItem = *handlePut*(request);
> } else if (DELETE_SYNONYMS.contains(operation)) {
> responseItem = handleDelete(request);
> } else {
> ..
>
>
> As per,
> http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/restful-protocol<http://www.google.com/url?sa=D&q=http%3A//www.opensocial.org/Technical-Resources/opensocial-spec-v081/restful-protocol>,
> section 3 - Operations:
>
> 3. Operations
>
> OpenSocial uses standard HTTP methods: GET to retrieve, PUT to update in
> place, POST to create new, and DELETE to remove. POST is special; it
> operates on collections and creates new activities, persons, or app data
> within those collections, and returns the base URI for the created resource
> in the Location: header, per AtomPub semantics.
>
> Restricted clients, or clients behind restricted clients, which cannot use
> PUT or DELETE SHOULD translate PUT and DELETE to POST operations with an
> additional X-HTTP-Method-Override: header: POST /... HTTP/1.1 ...
> X-HTTP-Method-Override: PUT
>
