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