On Dec 30, 2009, at 11:58 AM, Adam Retter wrote:
>> Note that from the client perspective they should not really care
>> too much
>> about the URIs and how to construct them as it is usually the
>> server that
>> informs the client on how to do that with links embedded in
>> representations.
>
> I am wondering in this case how the server would inform the client
> about the available URI's?
>
> Do you mean that http://www.company.com/rest/lodgement could return a
> list of URI's in some form?
That is one way.
> If this is the case, then we really dont
> want this functionality. Our clients must already know their keys's
> for their lodgements.
>
Or one could use a URI template:
<keys template="
http://www.company.com/rest/lodgement/{key}">
<document template="
http://www.company.com/rest/lodgement/{key}/pdf">
Note that you could also use content negotiation on the first type of
URI to return the XML with embedded PDF or the PDF document. And if
required you could set of URI conneg so that:
http://www.company.com/rest/lodgement/XYZ.pdf
does the equivalent of a client using
http://www.company.com/rest/lodgement/XYZ
with an appropriate Accept header.
IMHO that is a better, looser coupled, solution leaving the
possibility to easily add further document formats if required in the
future.
>> If you specify to clients how to construct URIs as part of a
>> documented
>> contract then it increases coupling between the client and server
>> and thus
>> makes it harder to evolve the server. If you understand this and the
>> tradeoffs but still want to do that then it is OK :-)
>
> I think that may be the only solution for us. Unless you can think of
> another idea, basically clients store lodgements with us and they
> generate the key for the lodgement themselves, they then retrieve this
> lodgement later using the key.
>
I think the use of URI templates could be appropriate.
>> The logical relationship between "Lodgement" key and PDF looks
>> good. IMHO i
>> prefer something like "server" or "api" to "rest".
>>
>> I was wondering if may be possible to use the same URI for both
>> non-authenticated and authenticated requests depending on if the
>> client uses
>> https and sends a client certificate? that might be cleaner but is
>> likely to
>> depend on features of the web/app server to enable this. Otherwise
>> if that
>> is not possible using distinct URI path to distinguish between
>> authenticated
>> and non-authenticated is is an appropriate solution (and it might be
>> appropriate to deploy two servlets in this respect).
>
> Hmm, I also wondered if this would be possible but I have not yet
> found a way to do this. Perhaps you have some ideas?
>
Not really, it may well be possible in GlassFish or stand alone
Grizzly. I think it requires that you ask on appropriate lists for web/
app servers.
> Basically we use Tomcat and Apache httpd linked together using AJP.
> Apache httpd ssl is configured to require an SSL from the client when
> accessing /rest/secure/*
> It may be possible to do this in Tomcat as opposed to Apache httpd,
> and switch to using reverse proxying instead of AJP, but again I
> think Tomcat only provides static configuration for describing which
> paths require client certificates.
>
> It would be really nice if I could use annotations to describe the
> security levels of paths in my JAX-RS classes, but I guess this would
> require support or some sort of integration with the application
> server.
>
Yes that is possible. If you do not want to use EJBs and JAX-RS (with
Java EE 6 such capabilities are vastly easier to use than with Java EE
5) you can use Jersey's support for filters and use the @RolesAllowed
annotation and/or define your own resource filter/annotation. For more
details see my response to another developer on this topic:
http://markmail.org/search/?q=list
%3Anet.java.dev.jersey.users#query:list%3Anet.java.dev.jersey.users
+page:1+mid:w6ietnvq43orucpj+state:results
Paul.