Thanks Paul
For JSON-RPC in PHP if you don't handle a service in ApiServlet then it
produces a ResponseItem with an error field set. The batch nature of the
request correctly returns the error for this field while returning the results
for the other fields. So you are correct. And thanks for the steer re. the
special case of people data and filter or sort options.
Re. how to throw a NOT_IMPLEMENTED error for a whole Service; the PHP v1.1 code
appears to have an error as detailed:
In ApiServlet->handleRequestItem the idea is to match the type of service and
set up the handler for the service. If the service is not matched the default
case is:
throw new SocialSpiException("The service " . $requestItem->getService() . " is
not implemented", ResponseError::$NOT_IMPLEMENTED);
but this throws a PHP fatal error which results in a 500 - because the throw
statement is executed outside of a try.. catch block.
The correct code, visible elsewhere , is to throw the Exception and catch it
and use it to build the ResponseItem. E.g. an error thrown in
JsonDbopensocialService is caught in DataRequestHandler->handleItem() where the
ResponseItem is built and returned. In the JSON-RPC route this is added to the
total result set and in the Rest route a method sendError in DataServiceServlet
uses it to add the correct HTTP header e.g. 501 for Not Implemented. I think in
this case the author missed that we are outside of a try catch block.
So, if I'm right:
In ApiServlet->handleRequestItem:
try { throw new SocialSpiException("The service " .
$requestItem->getService() . " is not implemented",
ResponseError::$NOT_IMPLEMENTED); } catch
(SocialSpiException $e) { $response = new
ResponseItem($e->getCode(), $e->getMessage()); return $response;
}
should replace:
throw new SocialSpiException("The service " . $requestItem->getService() . " is
not implemented", ResponseError::$NOT_IMPLEMENTED);
as the fall-back in the case statement.
What is the procedure for reporting this?
Thanks
Justin
> Date: Thu, 24 Jun 2010 07:21:49 -0700
> Subject: Re: NOT_IMPLEMENTED - supporting just part of a service
> From: [email protected]
> To: [email protected]
>
> For JSON-RPC batches you should be able to return not-implemented for
> specific requests with the others going through. (Though I'd have to check
> how PHP handles this vs Java)
>
> Also note that there are slightly different standards for portable contacts
> (aka people) requests. Those responses have filtered/sorted/updatedSince
> fields for this purpose. See:
>
> http://portablecontacts.net/draft-spec.html#declining
>
>
> On Thu, Jun 24, 2010 at 3:44 AM, Justin Wyllie
> <[email protected]>wrote:
>
> >
> > Hi
> > Let's say we basically implement the people service but we do not support
> > getting friends who have an app, The filterBy field of 'hasApp'.
> > In the case of a JSON-RPC call this might return a data structure with
> > results for some labels e.g.
> > "result":{"startIndex":0,"totalResults":1,"itemsPerPage":20,"list":[{"id":"john.doe","isOwner":true,"isViewer":false,"name":{"familyName":"Doe","givenName":"John","formatted":"John
> > Doe"},"displayName":"Johnny"}
> > but for the label hasAppViewerFriend we might see
> > "error":{"code":501,"message":"Not Implemented"}
> > For Rest because it is a single call it seems we return NOT_IMPLEMENTED to
> > the whole request.
> > My question is - is this the correct way to deal with the case of partially
> > supporting a service?
> > Thanks
> > Justin
> >
> >
> >
> > _________________________________________________________________
> > http://clk.atdmt.com/UKM/go/197222280/direct/01/
> > Do you have a story that started on Hotmail? Tell us now
> >
_________________________________________________________________
http://clk.atdmt.com/UKM/go/195013117/direct/01/
We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now
