Marc Hadley wrote:
> On Jan 17, 2008, at 6:08 PM, Bill Burke wrote:
>
>> * Path, header and matrix params should be allowed to be convertable
>> primitive types (int, float, etc...)
>>
> Agreed, this is already implemented in Jersey.
>
As well as classes with a constructor that takes a String parameter or a
static valueOf(String) method.
We have had requests to support a broader range of types, see this issue
logged against Jersey [1], that uses joda-time DateTime as a use-case.
>> * I asked for this before, but I'd like to be able to inject a
>> PathSegment as a @PathParam:
>>
>> @GET @Path("{foo}/{bar}")
>> public String get(@PathParam("foo") PathSegment foo, @PathParam("bar")
>> PathSegment bar) {...}
>>
> Agreed, this would be useful for working with matrix parameters.
>
More discussion here:
https://jsr311.dev.java.net/servlets/ReadMsg?list=dev&msgNo=803
>> * I asssume Response.ResponseBuilder.created() sends a Location header
>> to the client?
>>
> Yes, I'll make that explicit in the javadoc.
>
>> * Two methods to Response.ResponseBuilder should be added:
>>
>> temporaryHostRedirect(String path);
>
> Yes, there are probably several others that would be useful.
>
>>
>> created(String path);
>>
>> This path should be concatenated to the base URI of the REST engine.
>> For example, if JAX-RS is deployed from a WAR under
>> http://www.jboss.org/REST
>>
>> Then:
>>
>> created("/customers/3424234"); should send a location:
>> http://www.jboss.org/REST/customers/3424234
>>
>> I believe redirects will be a common thing given it is a usage pattern
>> in books like Restful Web Services. We need an easy way to create
>> these URIs.
>>
> So essentially
>
> created("somepath")
>
> would be a shortcut for
>
> created(UriInfo.getBaseUriBuilder().path("somepath").build())
>
> For the example you give above (assuming you have a Customer resource
> with @Path("customers/{id}") you could also do something like
>
> created(UriInfo.getBaseUriBuilder().path(Customer.class).build("3424234"))
>
> which perhaps we could shorten to:
>
> created(Customer.class, "3424234")
>
The RI already supports the conversion of a relative URI to an absolute
URI for the Location header. Before the Location header value is
committed the impl checks to see if it is a relative URI and if so the
absolute URI of the request is used as the base URI to resolve. I think
that makes more sense that using the base URI of the application as
there is often a hierarchical relationship between the creating resource
and the created resource. For example:
@Path("collection")
public class CollectionResource {
@POST
public Response createEntry(byte[] entry) {
String entryId = ...
Response.created(UriBuilder.fromPath(entryId));
}
}
If the application is deployed at the base URI:
http://foo.com/base/
and the entryId value is:
1234
then the Location header is:
Location:
http://foo.com/base/collection/1234
Using a String for created might be OK but i think that String value
should be a compliant URI and any errors in parsing should be reported
by the created method. This also avoids issues with encoded/decoded form
and the UriBuilder can be used to safely create a relative URI from a path.
>> * How about replace @Path with @Uri "Uri" doesn't conflict with "URI".
>>
> I think path is more descriptive since the value is one or more path
> segments rather than a complete URI. It used to be @UriTemplate but we
> renamed it to @Path for this reason.
>
+1
>> * I'd like to add two types of wildcards to @Path mappings: '*' and
>> '**'. The would basically work like Ant expressions. '*' would only
>> consume one path segment, while '**' would consume multiple.
>>
>> @Path("**/*.jsp") maps to any path ending in ".jsp"
>>
>> @Path("*.jsp") only maps to one path segment of .jsp files.
>>
>> @Path("**/foo/**/bar") matches with "x/y/z/foo/1/2/bar"
>>
>> Also '**' could be used with a PathParam and PathSegment:
>>
>> @Path("customers/{id}**/address")
>> @GET
>> public String getAddress(@PathParam("id") PathSegment[] id) {...}
>>
>> The interesting side effect with having wildcard ability is that
>> JAX-RS could totally replace Servlets.
>>
> Rather than make up something new, I'd rather follow the UriTemplate
> syntax when that gets more stable:
>
> http://tools.ietf.org/html/draft-gregorio-uritemplate-02
>
I am wondering if we can address Bill's requirements using the new
template syntax but i have not had time to look at things in more detail
to determine what sub-set can work for matching and if the syntax is
easy to understand from a matching perspective.
Paul.
[1]
https://jersey.dev.java.net/issues/show_bug.cgi?id=15
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109