Extending the restrpc binding output data

[Tom-237]

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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Simon Laws]

Tom, some comments below

Regards

Simon

On Nov 22, 2007 9:08 AM, Tom <msctom@...> wrote:

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. 

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.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Tom-237]

Simon,

Great thing you like the idea. Some new thoughts below.

On 22 Nov, 11:50, "Simon Laws" <simonsl...@...> wrote:
> > 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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Simon Laws]

On 22 Nov, 12:57, Tom <msc...@...> wrote:

> Simon,
>
> Great thing you like the idea. Some new thoughts below.
>
> On 22 Nov, 11:50, "Simon Laws" <simonsl...@...> wrote:
>
> > > 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
> 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

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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Tom-237]

On 23 Nov, 08:47, simonsl...@... wrote:
> 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.

> 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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Simon Laws]

On 23 Nov, 09:40, Tom <msc...@...> wrote:

> On 23 Nov, 08:47, simonsl...@... wrote:
>
> > 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.
>
> > 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

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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---