Marc Hadley wrote:
> You can still look at the code to figure out how to invoke the service,
> the existing @Path and @ProduceMime semantics are preserved by this
> proposal, i.e. you can still use the "platonic" URI with an Accept
> header to select the representation.
>
How? Is the extension string somehow extracted from the @ProduceMime
metadata or from some other annotation?
>> I think supporting the URI template standard Paul linked in a previous
>> alternate thread gives us much more power than what you're suggesting
>> and is a cleaner approach to implement this idea.
>>
>>
>> @Path("/{resource}.xml")
>> @GET
>> public String getXML(@PathParam("resource") String id) {}
>>
>> @Path("/{resource}.html")
>> @GET
>> public String getHTML(@PathParam("resource") String id) {}
>>
> The problem with that is that you have to have separate methods or
> classes for each media type/extension you want to support and
> potentially separate ones for platonic uris with Accept.
Not if you have rich expressions:
@Path("/{resource}((.html)|(.xml))*")
@ProduceMime("text/html", "application/xml")
public String getHTML() {}
FYI: I couldn't figure out how to do this with:
http://tools.ietf.org/html/draft-gregorio-uritemplate-02
So I mixed in a regular expression.
> Essentially you
> are putting media type information into two places (@Path and
> @ProduceMime).
>
How is there only one place with your proposal? With yours, instead of
@Path and @ProduceMime, its [some proprietary configuration] and
@ProduceMime.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com