Discussion:
Extending the restrpc binding output data
Tom
2007-11-22 09:08:20 UTC
Permalink
Currently the restrpc binding will only return data in XML format.

Unless anyone has a better suggestion we will be extending our
installation of phosoa to check the Accept header of the client to
determine the format of return data.

By doing this we plan to add support for JSON return data. We'd be
glad to contribute this extension to the CVS once it's finished.
Simon Laws
2007-11-22 10:50:38 UTC
Permalink
Tom, some comments below

Regards

Simon
Post by Tom
Currently the restrpc binding will only return data in XML format.
Unless anyone has a better suggestion we will be extending our
installation of phosoa to check the Accept header of the client to
determine the format of return data.
Sounds like a good idea to me. There is the opportunity in
restrpc/Server.php to convert the response into the required output format
so I think this will work.
Post by Tom
By doing this we plan to add support for JSON return data. We'd be
glad to contribute this extension to the CVS once it's finished.
Sounds good to me. There is code in the jsonrpc binding for the conversion
into JSON. In SCA_ServiceWrapperJson.php you'll find

// convert the reponse from the message call into something
// that can be copied into a JSON result string by the
// JSON Server
if ( $return == null ) {
$response_object = "null";
} else if ( is_object($return) ) {
$response_object = $this->json_das->encode($return);
} else if ( is_array($return) ) {
throw new SCA_RuntimeException("Return from method
$method_name of type array found. " .
"Return types must be either primitives or SDOs");
} else {
$response_object = json_encode($return);
}
Which checks the response type and does the appropriate conversion.

The json das must be set up based on the the schema that describes the types
in the service interface if you are expecting json to be passed into the
service. In your case you are only talking about encoding return types so
you can get away without doing this I think. If you look at the constructor
for the SCA_ServiceWrapperJson you can see the das being created.

Would be great to have this contributed back into CVS so thanks for the
offer.
Tom
2007-11-22 12:57:24 UTC
Permalink
Simon,

Great thing you like the idea. Some new thoughts below.
Post by Simon Laws
Post by Tom
Currently the restrpc binding will only return data in XML format.
Unless anyone has a better suggestion we will be extending our
installation of phosoa to check the Accept header of the client to
determine the format of return data.
Sounds like a good idea to me. There is the opportunity in
restrpc/Server.php to convert the response into the required output format
so I think this will work.
Using only the Accept header turns out to be impractical when calling
the API from a browser based script when not using the XMLHTTPRequest
object, since it's then not possible to modify the request header in
any way.

My suggestion is to, instead of looking at the accept header, or as an
override possibility, add an optional parameter after the method name:

That would make these calls valid:
/MyService.php/myMethod/json?a=b&c=a returns JSON
/MyService.php/myMethod/xml?a=b&c=a returns XML
/MyService.php/myMethod?a=b&c=a returns XML for backwards
compatibility

Regards

/Tom
simonslaws-gM/Ye1E23mwN+
2007-11-23 07:47:33 UTC
Permalink
Post by Tom
Simon,
Great thing you like the idea. Some new thoughts below.
Post by Simon Laws
Post by Tom
Currently the restrpc binding will only return data in XML format.
Unless anyone has a better suggestion we will be extending our
installation of phosoa to check the Accept header of the client to
determine the format of return data.
Sounds like a good idea to me. There is the opportunity in
restrpc/Server.php to convert the response into the required output format
so I think this will work.
Using only the header turns out to be impractical when calling
the API from a browser based script when not using the XMLHTTPRequest
object, since it's then not possible to modify the request header in
any way.
My suggestion is to, instead of looking at the accept header, or as an
/MyService.php/myMethod/json?a=b&c=a returns JSON
/MyService.php/myMethod/xml?a=b&c=a returns XML
/MyService.php/myMethod?a=b&c=a returns XML for backwards
compatibility
Regards
/Tom
Hi Tom

If you can't manipulate the accept headers can you use the JSONRPC
binding which will return JSON formatted messges? Looking at the code
it seems that the JSONRPC binding will only handle POST requests in
JSON format at the moment. There is a TODO about parsing GETs but the
code from the RESTRPC binding could be used here to get the effect I
think you are after. I.e. HTTP params in, JSON out.

If that isn't a viable alternative then I don't have a particular
objection to adding the path info. I'd like to understand a little
more about the problem setting accept headers though as that sounded
like a neater solution. What mechanism are you using for making the
calls from the browser?

Regards

Simon
Tom
2007-11-23 09:40:01 UTC
Permalink
Post by simonslaws-gM/Ye1E23mwN+
If you can't manipulate the accept headers can you use the JSONRPC
binding which will return JSON formatted messges? Looking at the code
it seems that the JSONRPC binding will only handle POST requests in
JSON format at the moment. There is a TODO about parsing GETs but the
code from the RESTRPC binding could be used here to get the effect I
think you are after. I.e. HTTP params in, JSON out.
That might be a good idea. However at the moment we've already
refactored and extended the restrpc binding to do this. And we've also
improved the GET parsing in the restrpc binding, so we are
concentrating on that one. We're still fine tuning and adding error
handling (output of error messages in json/xml when exceptions occur).
I'll publish the code once it's done for your review.
Post by simonslaws-gM/Ye1E23mwN+
If that isn't a viable alternative then I don't have a particular
objection to adding the path info. I'd like to understand a little
more about the problem setting accept headers though as that sounded
like a neater solution. What mechanism are you using for making the
calls from the browser?
At Tablefinder we use a very very stupidly simple way to do REST JSON
calls. We just do this:
<script type="text/javascript" src="http://
api.two.coreweb.lab.tablefinder.com/v1/Restaurants.php/listRestaurants/
json?apiClientId=ss"></script>

As you can see there's no way to set the headers here :) The pattern
is called Dynamic Script Include and eliminates the need to use the
XMLHTTPRequest object in the browser. It also allows cross-site
scripting which enables widgets and 3rd parties to access the API even
though they're not on the same domain as our API.


Regards,

Tom
simonslaws-gM/Ye1E23mwN+
2007-11-23 10:03:48 UTC
Permalink
Post by Tom
Post by simonslaws-gM/Ye1E23mwN+
If you can't manipulate the accept headers can you use the JSONRPC
binding which will return JSON formatted messges? Looking at the code
it seems that the JSONRPC binding will only handle POST requests in
JSON format at the moment. There is a TODO about parsing GETs but the
code from the RESTRPC binding could be used here to get the effect I
think you are after. I.e. HTTP params in, JSON out.
That might be a good idea. However at the moment we've already
refactored and extended the restrpc binding to do this. And we've also
improved the GET parsing in the restrpc binding, so we are
concentrating on that one. We're still fine tuning and adding error
handling (output of error messages in json/xml when exceptions occur).
I'll publish the code once it's done for your review.
Post by simonslaws-gM/Ye1E23mwN+
If that isn't a viable alternative then I don't have a particular
objection to adding the path info. I'd like to understand a little
more about the problem setting accept headers though as that sounded
like a neater solution. What mechanism are you using for making the
calls from the browser?
At Tablefinder we use a very very stupidly simple way to do REST JSON
<script type="text/javascript" src="http://
api.two.coreweb.lab.tablefinder.com/v1/Restaurants.php/listRestaurants/
json?apiClientId=ss"></script>
As you can see there's no way to set the headers here :) The pattern
is called Dynamic Script Include and eliminates the need to use the
XMLHTTPRequest object in the browser. It also allows cross-site
scripting which enables widgets and 3rd parties to access the API even
though they're not on the same domain as our API.
Regards,
Tom
Neat! I see why you can't set headers. So yes, if you want the
response format to be selectable from the browser it looks like you've
going in the right direction. If you want to be able to configure it
at the server then the thing to do would be consider adding some
parameterization to the binding (@binding.restrpc json for example)

Regards

Simon

Loading...