On 8/21/2012 5:45 AM, Sergey Beryozkin wrote:
> Hi,
> On 21/08/12 01:22, Santiago Pericas-Geertsen wrote:
>>
>> On Aug 20, 2012, at 5:22 PM, Bill Burke wrote:
>>
>>>>> I wonder if we should just limit the support of media types to the
>>>>> 'type' attribute and postpone the support for multiple
>>>>> produces/consumes types when we have some realistic cases
>>>>
>>>> Perhaps, but people that have extended JAX-RS with hyperlinks have
>>>> found this additional meta-data to be useful.
>>>>
>>>
>>> In my experience, this type of metadata is rarely used as
>>> machine-based clients are just looking for the rel and the href. Even
>>> so, "rel" attribute is enough self-describing metadata for the client
>>> to know what to do as its either registered with IANA, or a URL you
>>> can query.
>>
>> Perhaps we should stick to the standard attributes but leave the
>> capability to define extensions (not unlike arbitrary HTTP headers) and
>> let them worry about their syntax?
>
> This would be my preference, have standard attributes (as defined in
> RFC) supported explicitly, the parameters map is there to accommodate
> for the extensions if any.
>
>> I'd rather us not over-specify things
>> here; I'm on the fence with the attribute 'method', though.
>
> it does not harm but as I said I can see it working with the 'consumes'
> extension together, with the idea being that knowing the method and what
> the 'target' accepts, one can post/put to it.
>
> I'd drop the explicit support for 'produces', and either keep the
> explicit support for consumes + method or drop both. If we were to keep
> them then I'd also rename 'consumes' to 'accept' to give it a more
> JAX-RS-neutral name
>
you don't need consumes either as the 'type' attribute covers it.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com