8:29 p.m.
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.