Henning, Thanks for the quick fix!
Shishir On Tue, Jan 13, 2009 at 4:25 PM, Paul Lindner <[email protected]> wrote: > Indeed, this is a bug. Thanks Henning/Shishir! > > > On Jan 12, 2009, at 5:14 PM, Henning Schmiedehausen wrote: > > 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 >>> >>> > -- Diogenes - "What I like to drink most is wine that belongs to others."
