>>
>> Is this scenario, are you trying to cover the case where you don't
>> have access to the application artifacts to properly set the necessary
>> mapping annotations from JAX-RS ?
>
> It was about existing SCA services that you now want to expose as a
> REST endpoint so they wont have any JAX-RS annotations.
>
>> What is the difference between this
>> and the usage of Collection interface pattern that maps the HTTP
>> operations to specific method operations ?
>>
>
> I'm not sure, could you give an example of what the Collection
> interface pattern looks like?
>
>>> <binding.http>
>>> <wireformat.json>
>>> <operationselector.custom class="some.UserClass"/>
>>> </binding.http>
>>>
>>> How does that sound?
>>>
>>
>> About the wireFormat, I think there are two scenarios :
>> - I want to always force a specific wireFormat, then configuring it
>> on the composite is fine and wireformat.json seems ok
>> - I want to make things flexible, based on how HTTP uses
>> acceptHeaders to identify what type of payload it is expecting on the
>> response, and for this I was thinking about having something more like
>> <wireformat.httpAcceptHeader> and then do some magic using dataBinding
>> or throwing somekind of HTTP error code back if format is not
>> supported.
>>
>
> Sure, wireformat.json was just one example, having one that can do
> more based on headers sounds good.
>
>
>> Now, regarding the operationSelector, what did you have in mind with
>> this custom one ? Mainly map HTTP operation to methods based on a
>> convention over configuration pattern ?
>
> This bit I'm not sure about yet, requiring the implementation to have
> GET/PUT/etc operations doesn't seem perfect to me so i was think the
> operation selector could do more than that. But i think we should talk
> to the spec people, try a few things, see what works and what doesn't.
If we think back to the work we all did when we brought the
wireFormat/operationSelectors into JMS there was quite a lot of
discussion about a custom approach [1]. Looking back we didn't record
any detail about custom operation selection although I remember some
discussion. In the REST case you could imagine a variation on the
theme already presented.
<binding.http>
<wireformat.json>
<operationselector.custom class="some.UserClass">
<operation name="doSomething" verb="get"/>
<operation name="doSomethingElse" verb="put"/>
</operationselector.custom>
</binding.http>
However note that the current draft of the HTTP spec has the concept
from JMS of operation property mapping and so the interplay of
operation selection and this concept could/should be explored.
This sort of thing seems clumsy if it's mandatory in every case but if
it's only required where the normal JAXRS model is not possible then
it seems reasonable.
>
>>
>> BTW, I've started prototyping something very basic support for this,
>> on top of http binding we have today... let me know if you want to
>> collaborate, and maybe i could get this going as a copy of the current
>> binding to avoid any breakages...
>>
>
> Sure ok, how about we start a new HTTP binding for this based on the
> OASIS draft spec.
+1 new binding. Gives a platform for experiment.
>
> ...ant
>
Regards
Simon
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Response+Binding
