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@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