2009/12/30 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>
> 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">
What are these URI templates? Can you give me some pointers to where I
can find out more about them please?
> 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.
Ah yes, Content Negotiation is a good idea :-) I guess thats with the
@Consumes annotation?
But actually I simplified a little bit in my examples.
http://www.company.com/rest/lodgement/XYZ/pdf
Doesnt actually return the PDF of the lodgement, it returns a custom
XML document which embeds one or two PDF's, sometimes a lodgement has
a related lodgement, the requirement I had was to return the pdf (or
both if there is a related lodgement) from a single key.
So I have modified my URI scheme to this -
http://www.company.com/rest/lodgement/XYZ/pdfs (note the 's' on the end)
This will return the associated pdf(s) embedded in a custom XML
document. So /pdfs is a kinda operator really describing a processing
action, not sure if my URI scheme reflects that or not? Or perhaps I
should really be using the query string for that?
I could still use content negotation in future with
http://www.company.com/rest/lodgement/XYZ to return just the XML or
PDF aspect :-)
>>> 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
Will take a look into this asap, thanks very much :-)
> Paul.
>
> ---------------------------------------------------------------------
> 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