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.