Hi all,
while implementing JAX-RS there are some new questions about it:
*name JAX-RS*
The name JAX-RS is not realy good, because the X stands for XML. But
JAX-RS should not required XML, as also pointed out in the goals of spec
(see section 1.2). What about JA-RS?
I know that this questions comes late, but this mind comes not earlier.
*_at_Context on PathSegment?*
What about @Context also allowed on type PathSegment? I know that it is
also possible by using UriInfo.getPathSegments() and then fetch the
last, but this raises the useability. It should be the last parsed path
segment:
* On a resource method the PathSegment that was parsed while looking
for the resource class (if it is a root resource class that from
@Path of the class)
* On a sub resource method or locator it is the one from @Path of
the java method.
*".." in @Path*
Perhaps I've requested it again, but I found nothing about it in the
spec neither in the javadoc of @Path: IMO ".." and perhaps "." at the
start must not be allowed in @Path
*avoid body conversion to entity if not needed*
The conversion of the entity by the entity provider may take time. To
avoid unneeded conversions, it could be useful to add a method
Request.getEntity(), which processes the entity not earlier before the
method is called. If the entity is not needed (e.g. if a precondition
fails or no concrete resource method could be found) the time for
unnecessary conversion could be saved.
The consequence would be, that the altering of HTTP headers is not
possible in the MessageBodyReader. Because it is not needed in the most
cases, a solution could be, that a MessageBodyReader could answer if it
changes the headers or only reads them (or perhaps don't at all needs
it). This could be realized by a method on the MessageBodyReader
returning one enumeration value of CHANGE, READ or NOT_NEEDED. The last
value could save time in some implementations to convert the HTTP
headers, if the runtime environment now, that they are not needed, and
can inject null, and perhaps save a conversion.
The same is also useful on MessageBodyWriters: If the runtime env know,
that the MessageBodyWriter do not change or need the headers, it could
send the headers to the client earlier. I think the headers are needed
only in a very little number of cases.
*What if @*Param value is not available?*
If a @*Param value (e.g. a matrix parameter value) is not available,
what should be the value for the variable? IMO it is useful to define
explicit, that it must be null, but I found no definition for this.
e.g.: new Integer(String) could not return null and
Integer.valueOf(String) will throw a NumberFormatException.
String.valueOf(String) is not available. @DefaultValue(null) is not
possible (compiler error) and if it would be possible, than it is also
not useful (IMO).
I think it is useful to define, that if the value is not available, to
go round static valueOf(String) and new XXX(String) and directly use null.
Another question is what happens, if a value is not available for a
primitive type. For a @MatrixParam status 404 (not found) is useful (at
least in a lot of cases). For @PathParam status 500 (server error,
because the app developer must ensure, that the path variable is
available) is useful IMO. For @QueryParam, @CookieParam and @HeaderParam
I don't know anything except 400 (bad request).
Give zero or Integer.MIN_VALUE is a terrible solution (IMO), because it
suggests, that there is a value, but there is no.
*javadoc
*
* The javadoc of @HeaderParam points out, that you have to use
HttpHeaders interface. It is also possible to use List<?>. Or is
this not specified yet, only discussed?
* Typing error: section Resoources.ResourceMesthods.Parameters:
first line of @MatrixParam, ...: "wth" must be "with"
* Marc, IMO is it useful to change all @ (@Path and so on) in the
javadoc to @ (HTML equivalent for @). Eclipse shows the
javadoc of a method, class and so on, if you move the mouse on it.
But because @see and so on starts with @, the parser thinks it is
such an javadoc annotation, but the javadoc parser don't know what
to do with @Path. So the text is broken there. If you want, I can
change it and send it as a SVN patch.
best regards
Stephan