[Pki-devel] Choosing a REST implementation

[Adam Young]

As we close in on the decision about REST, I'd like to mention one thing 
that Ade and I have been looking into:  which REST implementation to choose.

It seems like the world has settled in on JAX-B as the API of choice.  
This makes things as little easier for us, as it means we can program to 
a standard API  and swap out the libraries.  I've done what I call a 
Spike (  something less than a proof-of-concept,  more like poking a 
hole in the ground to see if something comes out) using the reference 
implementation:  Jersey.  With this I can do:

curl -H "accept: application/json"   -H "Accept: applicaton/json"  
http://$IPASERVER:8080/PKIREST/pki/certificates/2


And get back:

{"algorithmID":"RSA","issuer":"Fedora PKA Server 
Cert","serialNumber":"2","version":"0"}

as well as



  curl -H "accept: application/xml"   -H "Accept: applicaton/json"  
http://$IPASERVER:8080/PKIREST/pki/certificates

Which gets:

<?xml version="1.0" encoding="UTF-8" 
standalone="yes"?><certificates><certificate><algorithmID>RSA</algorithmID><issuer>Fedora 
PKA Server 
Cert</issuer><serialNumber>2</serialNumber><version>0</version></certificate><certificate><algorithmID>RSA</algorithmID><issuer>Fedora 
PKA 
CA</issuer><serialNumber>1</serialNumber><version>0</version></certificate></certificates>


So we have a library and an approach that can handle both XML and JSON 
without much fuss.


Note that this is just a  Plain Ole Java Object (POJO)  that is a place 
holder for a real certificate and not anything that ties in with our 
APIs.  As I said, a spike.


The other REST implementations I've checked out are RESTlet and 
RESTeasy.  Of them, RESTeasy is closer to home, as it is supported by 
the JBoss team, and is the JBoss REST Implementation of choice.  Both of 
them are complicated enough that it is not immediately clear how to go 
about integrating them into a pre-existing Serlvet app.  I'm sure it is 
not much different than the Jersey code base.

The questions then are:  does the Jersey implementation do everything 
that we foresee needing and how hard would it be to package.

I'll answer the packaging question first, as it is the easier one.


In order to productize the Jersey implementation for shipping with PKI 
I'd have to get the source for Jersey and make an RPM out of it:  
someone on the JPackage team has done this in the past, and it shouldn't 
be hard to move it forward to the latest Jersey implementation.

The Jersey implementation from the Oracle site provides:


asm-3.1.jar                   jackson-xc-1.8.3.jar     
jersey-server-1.9.1.jar
jackson-core-asl-1.8.3.jar    jersey-client-1.9.1.jar  jettison-1.1.jar
jackson-jaxrs-1.8.3.jar       jersey-core-1.9.1.jar    jsr311-api-1.1.1.jar
jackson-mapper-asl-1.8.3.jar  jersey-json-1.9.1.jar


Most of these are not in Fedora yet.   Only jettison.

asm is at an older version(2) but we should be able to get 3 in with a 
the name asm3,  which is what I think is already going to happen for 
Maven support.  I suspect it would not be that hard to package the 
others and get them into Fedora.  The source for all of them is in the 
Maven Repo:  http://download.java.net/maven/2/com/sun/jersey/  and 
converting Maven POMs to Spec files is straightforward enough that it 
can be automated.


The other REST implementations are in pretty much the same boat.  None 
of the mare packaged for Fedora, and most of them pull in quite a few 
other packages for Building.   Both RESTlet and RESTeasy are fairly 
heavy weight to build:  they both go beyond providing a library that 
interfaces with the Servlet API to providing full Servers, far more than 
we would want to support.  Lets just say that getting them to build as 
RPMs is a task that I would not be willing to take on in support of 
PKI.  There are a few others out there, but mostly they seem to be 
projects that were originally for web services that decided to add 
support for REST as well.


So then the question is: Does Jersey does everything we think we need it 
to do?  The short answer right now is that I don't know,  but I suspect 
so.  REST is basically making Heavy use of the HTTP  definition,  so 
really, the question is does it let us maximize things like redirects, 
response codes,  renegotiation and authentication.    This is the next 
stage of investigation, and I'll keep you posted.