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