[Pki-devel] Proposed RESTful interface to dogtag

Ade Lee alee at redhat.com
Tue Oct 18 15:34:13 UTC 2011


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





More information about the Pki-devel mailing list