On Sun, Jul 11, 2010 at 2:13 AM, Luciano Resende <[email protected]> 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
