On Tue, Aug 31, 2010 at 12:10 AM, Luciano Resende <luckbr1...@gmail.com> wrote:
> On Mon, Aug 30, 2010 at 3:51 PM, ant elder <antel...@apache.org> wrote:
>>
>> If you really want to have all this is in just a single binding then
>> why not call it binding.http? Merging this function into binding.rest
>> makes no sense at all. REST is not RPC.
>>
>> ...ant
>>
>
> I would like to have one binding, independent if we call it REST or
> HTTP... some approach to easily provide some transition to that path
> is also described in [1].
>
> [1] http://markmail.org/message/gooxl7dfaxahxr7h
>
Maybe we should think about what we really want this to look like,
what function binding.http supports, how those functions compare to
what other bindings do, and what wireFormats are supported.
Presently binding.http has a default wireformat that is really json,
or jsonp infact as it supports the same as what binding.jsonp does. In
1.x binding.http has a wireFormat.jsonrpc should we do that in 2.x
instead of or as well as the jsonrpc binding? There is also now a
wireformat.httpXml which supports sending and receive xml payloads.
And then there's also binding.rest which has all the JAX-RS functions.
I don't think there is a single correct answer for how to arrange all
that. There is a good chance that the user that wanted
wireformat.jsonrpc instead of binding.jsonrpc will want the same in
2.x. Conversely, it is simpler to type with individual bindings
instead of wireFormats, eg:
<binding.jsonp>
instead of:
<binding.http>
<wireFormat.jsonp/>
</binding.http>
Perhaps we should just support all the different approaches? It does
seem good if however we do it that there is minimal code duplication
so perhaps we should look at arranging the code so we can easily
support <binding.jsonp> scdl but that gets translated into a runtime
config thats shares all the code of the equivalent of binding.http
with wireFormat.jsonp.
Comments?
...ant
