You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/02/19 15:01:57 UTC
[C++] REST binding
I'm just having a crack at putting a PHP front end on the Alert sample and
have come up against some of the assumptions in the SCA Native Rest binding.
Is there a readme anywhere that describes what the valid combinations of
verbs and data are?
Looking at the code it seems that it assumes you are mostly dealing with XML
unless you are passing parameters in on a GET. Does the binding take any
account of the content type of the message? There are also some wrapping
sematics that it would be good to get an explanation of.
Thanks
Simon
Re: [C++] REST binding
Posted by Simon Laws <si...@googlemail.com>.
On 2/20/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Simon Laws wrote:
> > I'm just having a crack at putting a PHP front end on the Alert sample
> > and
> > have come up against some of the assumptions in the SCA Native Rest
> > binding.
> > Is there a readme anywhere that describes what the valid combinations of
> > verbs and data are?
> >
> > Looking at the code it seems that it assumes you are mostly dealing
> > with XML
> > unless you are passing parameters in on a GET. Does the binding take any
> > account of the content type of the message? There are also some wrapping
> > sematics that it would be good to get an explanation of.
> >
> > Thanks
> >
> > Simon
> >
>
> I've not looked at this code for a while but if I remember correctly
> here are the patterns that are currently supported.
>
> If the service/reference uses an <interface.rest> interface, we map CRUD
> methods to HTTP verbs to access resource representations as follows:
>
> resource = retrieve()
> -> GET <binding-uri>
> <- an XML element representing the REST resource
>
> resource = retrieve(uri, parm-value-1, parm-value-n)
> -> GET uri/parm-value-1/parm-value-n
> or if uri ends with a '?'
> -> GET uri?parm-name-1=parm-value1&parm-name-n=parm-value-n
> <- an XML element representing the REST resource
>
> uri = create(resource)
> -> POST <binding-uri> + an XML element representing the resource to create
> <- Location header containing the uri of the created resource
>
> update(resource)
> -> PUT <binding-uri> + an XML element representing the updated resource
>
> update(uri, parm-1, parm-n, resource)
> -> PUT uri/parm-value-1/parm-value-n + an XML element representing the
> updated resource
> or if uri ends with a '?'
> -> PUT uri?parm-name-1=parm-value1&parm-name-n=parm-value-n + an XML
> element representing the updated resource
>
> delete()
> -> DELETE <binding-uri>
>
> delete(uri, parm-1, parm-n)
> -> DELETE uri/parm-value-1/parm-value-n
> or if uri ends with a '?'
> -> DELETE uri?parm-name-1=parm-value1&parm-name-n=parm-value-n
>
> In this mode, HTTP return codes are used almost as described in the Atom
> spec. Also GET returns etags with the retrieved resource representations
> to help caching by clients.
>
> If the service/reference does not use an <interface.rest> interface,
> then this is not a real REST pattern, we simply flow method calls over
> XML / HTTP as follows:
>
> result = method-abc(parm-1, parm-n)
>
> if single input parameter of complex type
> -> POST <binding-uri>/method-abc + XML element representing the complex
> parameter
> or if multiple parameters including parameters of complex types
> -> POST <binding-uri>/method-abc + Mime multipart/form-data body
> containing one parameter per part
> or if multiple parameters all of simple types
> -> GET
> <binding-uri>/method-abc?parm-1-name=parm-1-value&parm-n-name=parm-n-value
>
> <- an XML element representing the result
>
> Most combinations are demonstrated in the RestCustomer and
> RestCalculator samples. It's pretty easy to run these samples and
> capture the HTTP traffic with an HTTP monitor.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> That's a great summary Jean-Sebastien. Thank you. I've copied here (
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+CPP+Bindings+REST)
for safe keeping. I got caught out in making the sample work in that the
existing binding doesn't support POSTing multiple simple type parameters.
Clear now it's spelled out:-) Anyhow I go round it by changing to GET for
the time being. I'll maybe look at this if I have time in the future.
Regards
Simon
Re: [C++] REST binding
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> I'm just having a crack at putting a PHP front end on the Alert sample
> and
> have come up against some of the assumptions in the SCA Native Rest
> binding.
> Is there a readme anywhere that describes what the valid combinations of
> verbs and data are?
>
> Looking at the code it seems that it assumes you are mostly dealing
> with XML
> unless you are passing parameters in on a GET. Does the binding take any
> account of the content type of the message? There are also some wrapping
> sematics that it would be good to get an explanation of.
>
> Thanks
>
> Simon
>
I've not looked at this code for a while but if I remember correctly
here are the patterns that are currently supported.
If the service/reference uses an <interface.rest> interface, we map CRUD
methods to HTTP verbs to access resource representations as follows:
resource = retrieve()
-> GET <binding-uri>
<- an XML element representing the REST resource
resource = retrieve(uri, parm-value-1, parm-value-n)
-> GET uri/parm-value-1/parm-value-n
or if uri ends with a '?'
-> GET uri?parm-name-1=parm-value1&parm-name-n=parm-value-n
<- an XML element representing the REST resource
uri = create(resource)
-> POST <binding-uri> + an XML element representing the resource to create
<- Location header containing the uri of the created resource
update(resource)
-> PUT <binding-uri> + an XML element representing the updated resource
update(uri, parm-1, parm-n, resource)
-> PUT uri/parm-value-1/parm-value-n + an XML element representing the
updated resource
or if uri ends with a '?'
-> PUT uri?parm-name-1=parm-value1&parm-name-n=parm-value-n + an XML
element representing the updated resource
delete()
-> DELETE <binding-uri>
delete(uri, parm-1, parm-n)
-> DELETE uri/parm-value-1/parm-value-n
or if uri ends with a '?'
-> DELETE uri?parm-name-1=parm-value1&parm-name-n=parm-value-n
In this mode, HTTP return codes are used almost as described in the Atom
spec. Also GET returns etags with the retrieved resource representations
to help caching by clients.
If the service/reference does not use an <interface.rest> interface,
then this is not a real REST pattern, we simply flow method calls over
XML / HTTP as follows:
result = method-abc(parm-1, parm-n)
if single input parameter of complex type
-> POST <binding-uri>/method-abc + XML element representing the complex
parameter
or if multiple parameters including parameters of complex types
-> POST <binding-uri>/method-abc + Mime multipart/form-data body
containing one parameter per part
or if multiple parameters all of simple types
-> GET
<binding-uri>/method-abc?parm-1-name=parm-1-value&parm-n-name=parm-n-value
<- an XML element representing the result
Most combinations are demonstrated in the RestCustomer and
RestCalculator samples. It's pretty easy to run these samples and
capture the HTTP traffic with an HTTP monitor.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org