<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 10/17/2011 08:35 PM, Adam Young wrote:
<blockquote cite="mid:4E9CC9C2.6020600@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 10/17/2011 08:10 PM, Jack Magne wrote:
<blockquote cite="mid:4E9CC3FA.3010605@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 10/17/2011 01:18 PM, Ade Lee wrote:
<blockquote
cite="mid:1318882723.30369.41.camel@localhost.localdomain"
type="cite">
<pre wrap="">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
</pre>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Pki-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Pki-devel@redhat.com">Pki-devel@redhat.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pki-devel">https://www.redhat.com/mailman/listinfo/pki-devel</a>
</pre>
</blockquote>
Thanks Ade. Just a few questions after having a look.<br>
<br>
1. I noticed we have the following key related resources:<br>
<br>
<br>
PUT /pki/key "Add a key"<br>
<br>
POST /pki/key "Modify a key"<br>
<br>
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?<br>
</blockquote>
I think you have it backwards. PUT is the normal way for creating
things. The POST operation is very generic and no specific meaning
can be attached to it. In general, use POST when only a subset of
a resource needs to be modified and it cannot be accessed as its
own resource; or when the equivalent of a method call must be
exposed.<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://developer.mindtouch.com/REST/REST_for_the_Rest_of_Us">http://developer.mindtouch.com/REST/REST_for_the_Rest_of_Us</a>
says this about POST:<br>
<br>
" usually either create a new one, or replace the existing one
with this copy, where as POST is kinds of a catch all. "<br>
<br>
We could possibly use PUT for both add and modify if we wanted. <br>
<br>
<br>
I tend to favor making objects immutable, and to replacing whole
objects when possible. However, I know that is not always
possible, especially when working with a pre-existing API. So I'd
say lets try to stick to PUT semantics where possible, but
deliberately use POST when we are making finer grain API calls.<br>
</blockquote>
<br>
And...now I am going to contradict that. I see that the general
wisom is to use POST if you want the server to create the unique ID
for you, and PUT if you know it a-priori....so we will probably be
using POST for things like Cert creation where the Serial number
comes from the server.<br>
<br>
<blockquote cite="mid:4E9CC9C2.6020600@redhat.com" type="cite"> <br>
<blockquote cite="mid:4E9CC3FA.3010605@redhat.com" type="cite"> <br>
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?<br>
<br>
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.<br>
<br>
I would imagine it would be a POST op like something as follows:<br>
<br>
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?<br>
</blockquote>
<br>
In general, REST works best if the service is stateless. Session
based information should be minimized if possible. <br>
<br>
<br>
<blockquote cite="mid:4E9CC3FA.3010605@redhat.com" type="cite"> <br>
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?<br>
</blockquote>
<br>
I am not a fan of annotations. Under other circumstances, I might
be prone to say "well, that is the way of the world" and go with
JAX-RS, but since we don not yet have a set of Entity objects that
would drive the JAX-RS, I am more prone to look at other
alternatives. THere are good libraries for serializing to JSON or
XML that should be sufficient for our needs, and that will keep
us from having to make our API conform to JAX-RS. So my
inclination is to say no to JAX-RS to start.<br>
<br>
<blockquote cite="mid:4E9CC3FA.3010605@redhat.com" type="cite"> <br>
thanks,<br>
jack<br>
</blockquote>
<br>
<br>
Ade's document has founds its way into the wiki world:<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://pki.fedoraproject.org/wiki/Dogtag_Future_Directions">http://pki.fedoraproject.org/wiki/Dogtag_Future_Directions</a><br>
<br>
<br>
I might have made some Wiki errors in translation. If this
contradicts Ade's spreadsheet, assume the spreadsheet is
Canonical.<br>
<br>
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Pki-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pki-devel@redhat.com">Pki-devel@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pki-devel">https://www.redhat.com/mailman/listinfo/pki-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>