On Sep 26, 2007, at 7:04 PM, Ryan McDonough wrote:
> I'm wondering if this logic could be tied to some of the content
> negotiation
> topics that we have been discussing in other threads?
> Fundamentally, the
> function of platonic URIs is another form of content negotiation but
> initiated by the URIs extension rather than the accept header. You
> could
> even go as far as saying it can override the accept header values
> if needed.
>
Yes, that's along the same lines I was thinking.
> While I'm all for the idea, I'm curious if we are potentially creating
> another logic path to do the same thing? I know it's a big change,
> but it
> may be worth considering a way to tie the extension to the
> @ProduceMime
> annotation.
Right, that's what I was suggesting in my last mail.
> Yes it could get ugly, but it will keep things consistent for
> both types of negotiation mechanisms. For example it could be that
> we have:
>
> @UriTemplate(value="{id}")
> @HttpMethod
> @ProduceMime(variants={_at_Variant("application/xml;q=0.7","xml"),
> @Variant("application/json;q=0.9","json")})
> SomeItem getItem(@UriParam("id") String itemId) {
>
I like the idea in general but I'm not sure it makes sense to put the
mapping information in an annotation like that. Seems to me that
you'd want to define the mapping once per application rather than per-
resource or per-resource method so I think we'd be looking at some
kind of per-application configuration file instead.
Off the top of my head we could support something like:
@UriTemplate("{id}")
@HttpMethod
@ProduceMime("application/xml")
SomeItem getItem(@UriParam("id") String itemId)
with a configuration file:
<application xmlns="...">
<extensions>
<extension value="xml" mediaType="application/xml"/>
<extension value="json" mediaType="application/json"/>
...
</extensions>
...
</application>
such that
GET /1.xml
Accept: */*
is treated identically to
GET /1
Accept: application/xml
Question: should an extension override an accept or enhance it, e.g.
should
GET /foo.json
Accept: application/xml
cause an error (assuming .json was mapped to application/json) or
should it effectively add application/json to the Accept value ?
Marc.
>
> On 9/26/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>>
>> On Sep 25, 2007, at 7:05 AM, Paul Sandoz wrote:
>>>
>>> I don't think it makes sense to support:
>>>
>>> /collection.xml/1
>>> /collection.xml/1.xml
>>>
>>> The suffices only makes sense on last path segment of the URI.
>>>
>> The use of sub-resource methods will make this quite complex and
>> possibly counter-intuitive. Would it make sense to match the URIs
>> above but to simply ignore the extensions on the path segments
>> matched to the parent class. E.g.
>>
>> @UriTemplate(value="collection" extensions=true)
>> public class SomeResource {
>>
>> @HttpMethod
>> SomeCollection getAll(@UriExtensions String exts[]) {
>> ...
>> }
>>
>> @UriTemplate(value="{id}" extensions=true)
>> @HttpMethod
>> SomeItem getItem(@UriParam("id") String itemId, @UriExtensions
>> String exts[]) {
>> ...
>> }
>> }
>>
>> With the above you want both
>>
>> GET /collection.xml, and
>> GET /collection/1.xml
>>
>> to work so it could be tricky to disallow GET /collection.xml/1.xml
>> since the URI to resource class matching algorithm first has to match
>> the SomeResource class before it can match the getItem method.
>>
>> Marc.
>>
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> CTO Office, Sun Microsystems.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>
>>
>
>
> --
> Ryan J. McDonough
> http://www.damnhandy.com
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.