REST frameworks like JAX-RS bring little value to our JSON/HTTP API,
since it is just a wrapper of the underlying binary detyped DMR protocol. Even if we did
use a framework we would still have to write the marshaling bits, which is the majority of
the implementation.
Good point. The question is if we are building a JSON RPC protocol over HTTP or a REST
interface.
The later requires some more bells and whistles. If we simply need an HTTP access point to
handle a JSON'ish RPC
protocol, then the embedded HTTPD might be sufficient.
I don't want to start a religious war over what REST actually means, but we would at
least need to consider things like
content negotiation, uniform interface constraints, etc. Typical reasons to build a
RESTful interface in the first place.
But let's move this to a separate thread.
> Missing runtime service (b)
that may result in more work are things like integration with a security subsystem
> and configuration. While a the Servlet API provides clear means to integrate with
JAAS for instance, we would need to specify and implement that on our own.
Since JAAS is a SE API, you can use it without using servlet. Also, the jdk http server
provides an impl for basic and digest auth as well as support for ssl (although these are
trivial to implement anyway)
Ok, thats good. I was wondering about TLS. Let's figure out how authentication should
actually work.
I think this will identify the requirements.
I would suggest a separate thread as well.
> c) simply means we constraint ourselves and users a
single deployment option.
> In Neuchatel we discussed the deliverable as a web application (war) that relies in
the remoting protocol internally
> and the flexibility it would have in terms of running the web-UI anywhere in your
system.
Actually what you propose is less flexible. As you know, GWT app the uses REST is just
static content and doesn't even need a java web server. You can run it on apache, in a
war if desired, or even directly off the filesystem.
Although from a topology perspective, I would imagine most would prefer the admin console
be ran from the dc. We would of course need to support additional configurations.
Doing remoting from the web server implies that you would be doing javascript http
requests to the servlet engine (I'm guessing using GWT-RPC?) which would then do a
remoting call to the DC. Instead you can just do a straight http request to the dc, and
you have half the transport and marshaling happening.
See my comments on this in a previous email.
Ike
