Re: [Pki-devel] Proposed RESTful interface to dogtag
On Mon, 2011-10-17 at 17:10 -0700, Jack Magne wrote:
On 10/17/2011 01:18 PM, Ade Lee wrote:
> Hi all,
>
> I tried to put this on the dogtag wiki, but it did not seem to work.
> Will chat with Matt.
>
> In the meantime, here is a copy for you guys to look at and comment on.
> It has most everything except the installation servlets and token
> operations (for which I need to think about the object model). If you
> look at the mapped servlets, you'll get a sense of what operations are
> covered in each URL mapping.
>
> This is a first cut -- hopefully a good starting point for discussion.
> So please comment away!
>
> Ade
>
>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
>
Thanks Ade. Just a few questions after having a look.
1. I noticed we have the following key related resources:
PUT /pki/key "Add a key"
POST /pki/key "Modify a key"
In my quick readings, it appeared that the POST method was favored for
creating brand new resources where PUT was used to modify existing
ones?
The above question is answered in a different part of the thread.
I also noticed that you have two GET versions of "pki/key".
Is that
kind of duplication encouraged? Or is that really just the same api
entity with different input payloads?
That was a mistake. I was thinking in terms of GET /pki/key and
GET /pki/key/X/details, similar to what I had for certificates and
requests.
2. You suggested I take a look at some of the TKS TokenServlet
stuff.
I noticed that we have a simple short list of servlets that appear to
return very short lived resources. Examples being, session keys ,
encrypted data , and a block of randomly generated data.
I would imagine it would be a POST op like something as follows:
POST /pki/tks/sessionKey , which would return a link to the key
itself? But does it make sense to have a "resource" for something so
short lived, or does this concept even belong in such a design?
Just because the resources are short-lived, does not mean that they are
not resources or should be in a restful design. To quote:
A resource is anything that’s important enough to be referenced as a
thing in itself. If your users might “want to create a hypertext link to
it, make or refute assertions about it, retrieve or cache a
representation of it, include all or part of it by reference into
another representation, annotate it, or perform other operations on it”,
then you should make it a resource
http://www.w3.org/TR/2004/REC-webarch-20041215/#p39
The fact is that these short lived resources are the raison d'etre for
the TKS. It would be quite strange to have the rest of the system be
represented in REST and the TKS operations not represented as such.
3. I was just curious about the Java back-end for this design. Will
we
be using the JAX-RS stuff that provides annotations in the java code
in order to hook all of this up?
thanks,
jack