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