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