You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2010/07/11 03:13:40 UTC
REST, WireFormats, ATOM, etc
Currently, the REST Binding allows configuring multiple wireFormats
that defines the payload format. In this scenario, the client/server
communication semantics are exactly the same independent of what is
being sent over the wire (JSON, XML, etc).
For other HTTP Based technologies, such ATOM, etc, which have their
own specification which define particular client/server communication
semantics; we have been creating specific bindings (e.g.
binding.atom).
How people think we should handle these types of bindings ?
1) continue with specific bindings for things like ATOM, etc
2) Investigate the possibility to have some kind of map between
wireFormat.ATOM to Binding.ATOM
3) Incorporate these type of bindings as wireFormats within the REST Binding
Thoughts ?
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: REST, WireFormats, ATOM, etc
Posted by ant elder <an...@apache.org>.
On Fri, Jul 23, 2010 at 8:46 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Fri, Jul 23, 2010 at 12:42 AM, ant elder <an...@gmail.com> wrote:
>> On Sun, Jul 11, 2010 at 2:13 AM, Luciano Resende <lu...@gmail.com> wrote:
>>> Currently, the REST Binding allows configuring multiple wireFormats
>>> that defines the payload format. In this scenario, the client/server
>>> communication semantics are exactly the same independent of what is
>>> being sent over the wire (JSON, XML, etc).
>>>
>>> For other HTTP Based technologies, such ATOM, etc, which have their
>>> own specification which define particular client/server communication
>>> semantics; we have been creating specific bindings (e.g.
>>> binding.atom).
>>>
>>> How people think we should handle these types of bindings ?
>>>
>>> 1) continue with specific bindings for things like ATOM, etc
>>> 2) Investigate the possibility to have some kind of map between
>>> wireFormat.ATOM to Binding.ATOM
>>> 3) Incorporate these type of bindings as wireFormats within the REST Binding
>>>
>>>
>>> Thoughts ?
>>>
>>
>> IMHO binding.rest should only do REST type things and non-REST would
>> be better in either binding.http or individual bindings. For the http
>> based protocols it seems like a reasonable idea to do them as
>> binding.http with wireFormats instead of individual bindings then all
>> the http processing type things such as setting headers, doing
>> authentication etc can be done in one place so the function is
>> consistent.
>>
>
> When the REST binding was created, a new name was given to avoid any
> disruption with people currently using binding.http... that was also
> necessary as we didn't really know what direction it would take and if
> all features in binding.http would still be supported. Today we do
> know that Binding.REST is a superset of Binding.HTTP and I'm not sure
> we really want to have two bindings doing kind of same thing (one with
> more features then other)
>
If the binding is going to be a superset of binding.http then it
should be renamed to something other than .rest so that is clear,
calling it .rest seems misleading or even oxymoronic. Perhaps i'm
missing what you mean, could you give some examples of function it has
thats a superset of what an http binding could do?
Going back to your original question; i think we should only do (3)
for things that really work in the REST way, (1) and (2) may both be
appropriate if we have a binding.http.
...ant
Re: REST, WireFormats, ATOM, etc
Posted by Luciano Resende <lu...@gmail.com>.
On Fri, Jul 23, 2010 at 12:42 AM, ant elder <an...@gmail.com> wrote:
> On Sun, Jul 11, 2010 at 2:13 AM, Luciano Resende <lu...@gmail.com> wrote:
>> Currently, the REST Binding allows configuring multiple wireFormats
>> that defines the payload format. In this scenario, the client/server
>> communication semantics are exactly the same independent of what is
>> being sent over the wire (JSON, XML, etc).
>>
>> For other HTTP Based technologies, such ATOM, etc, which have their
>> own specification which define particular client/server communication
>> semantics; we have been creating specific bindings (e.g.
>> binding.atom).
>>
>> How people think we should handle these types of bindings ?
>>
>> 1) continue with specific bindings for things like ATOM, etc
>> 2) Investigate the possibility to have some kind of map between
>> wireFormat.ATOM to Binding.ATOM
>> 3) Incorporate these type of bindings as wireFormats within the REST Binding
>>
>>
>> Thoughts ?
>>
>
> IMHO binding.rest should only do REST type things and non-REST would
> be better in either binding.http or individual bindings. For the http
> based protocols it seems like a reasonable idea to do them as
> binding.http with wireFormats instead of individual bindings then all
> the http processing type things such as setting headers, doing
> authentication etc can be done in one place so the function is
> consistent.
>
When the REST binding was created, a new name was given to avoid any
disruption with people currently using binding.http... that was also
necessary as we didn't really know what direction it would take and if
all features in binding.http would still be supported. Today we do
know that Binding.REST is a superset of Binding.HTTP and I'm not sure
we really want to have two bindings doing kind of same thing (one with
more features then other)
> So this:
>
> <binding.rest>
> <wireFormat.json/>
> </binding.rest>
>
+1, in this case, the wireFormat is really configuring how the payload
is sent over the wire and this is how I see wireFormat to be used.
> seems ok as its fine to have json payloads when using REST, but its
> not ok to do rpc style operations with rest so for jsonrpc it should
> be:
>
> <binding.http>
> <wireFormat.jsonrpc/>
> </binding.http>
>
My understanding is that wireFormat is used to configure how data is
sent over the wire. Using wireFormat.jsonRPC in a binding, implies
that it's going to use JSON over the wire, but it brings totally
different semantics to the service, requiring the client to not only
change how it parse the request/response but also how it make services
invocations. This is what I'm not sure I totally agree with.
Thoughts ?
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: REST, WireFormats, ATOM, etc
Posted by ant elder <an...@gmail.com>.
On Sun, Jul 11, 2010 at 2:13 AM, Luciano Resende <lu...@gmail.com> wrote:
> Currently, the REST Binding allows configuring multiple wireFormats
> that defines the payload format. In this scenario, the client/server
> communication semantics are exactly the same independent of what is
> being sent over the wire (JSON, XML, etc).
>
> For other HTTP Based technologies, such ATOM, etc, which have their
> own specification which define particular client/server communication
> semantics; we have been creating specific bindings (e.g.
> binding.atom).
>
> How people think we should handle these types of bindings ?
>
> 1) continue with specific bindings for things like ATOM, etc
> 2) Investigate the possibility to have some kind of map between
> wireFormat.ATOM to Binding.ATOM
> 3) Incorporate these type of bindings as wireFormats within the REST Binding
>
>
> Thoughts ?
>
IMHO binding.rest should only do REST type things and non-REST would
be better in either binding.http or individual bindings. For the http
based protocols it seems like a reasonable idea to do them as
binding.http with wireFormats instead of individual bindings then all
the http processing type things such as setting headers, doing
authentication etc can be done in one place so the function is
consistent.
So this:
<binding.rest>
<wireFormat.json/>
</binding.rest>
seems ok as its fine to have json payloads when using REST, but its
not ok to do rpc style operations with rest so for jsonrpc it should
be:
<binding.http>
<wireFormat.jsonrpc/>
</binding.http>
...ant