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
