> 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? If this is the case, then we really dont
want this functionality. Our clients must already know their keys's
for their lodgements.
> 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.
> 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?
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.
> HTH,
> Paul.
>
> On Dec 29, 2009, at 5:40 PM, Adam Retter wrote:
>
>> Hi there folks, I am very new to using Jersey and I just wanted to get
>> some feedback on the URI's I am using and whether I am following best
>> practice or if people have any suggestions for improvement?
>>
>> The main resource that we are interested in is called a "Lodgement".
>> Lodgements are an XML document with an embedded PDF (base64).
>> Lodgements are always referenced by a key. For our site some access
>> has to be public and some has to be secure (client certificates). The
>> following two URI's I am using as my roots for my REST services -
>>
>> Public - http://www.company.com/rest/
>>
>> Client Certificates - https://www.company.com/rest/secure/
>>
>>
>> We have the need for two services currently -
>>
>> 1) A service for the public to retrieve the PDF aspect of a Lodgement,
>> for which I have used the following URI scheme -
>>
>> http://www.company.com/rest/lodgement/{key}/pdf
>>
>>
>> 2) A service for authenticated users to retrieve the entire Lodgement,
>> for which I have used the following URI scheme -
>>
>> https://www.compay.com/rest/secure/lodgement/{key}
>>
>>
>> Does my approach meet the known best practices of RESTful URI's or
>> could it be improved in someway?
>>
>>
>> Thanks Adam.
>>
>> --
>> Adam Retter
>>
>> skype :adam.retter
>> http://www.adamretter.org.uk
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>
>
--
Adam Retter
skype :adam.retter
http://www.adamretter.org.uk