Future Enhancements for NetBeans REST Support

This wiki page is used to keep track of all the enhancement ideas for our REST support in NetBeans. Some of the ideas are from our own understanding of the shortcomings of the current implementation. Some ideas are from talking to our evangelists. Feel free to add comments and more ideas to this page.

Support for MIME Types Other Than XML

In the NetBeans 6.0 Preview release, we only support XML as the MIME type. Other formats such as JSON, ATOM and perhaps RDF are just as important if not more.


Since JSON is a very popular format in the Web 2.0 developer community given the popularity of JavaScript and its simplicity compared to XML, we should give this the highest priority. Paul sent out an email a while back regarding a jaxws extension that can marshal xml message into JSON and back while obeying the jaxb annotations using the Jettison libraries. It would be nice for the REST runtime to support a similar extenstion. This means that we can reuse our generated JAXB-annotated converter classes as is to produce JSON representations. All we need to do is generate additional HTTP methods that consumes and produces JSON MIME type.

Note: JSON support should be added to the REST runtime after it goes open source on 6/15/07.


There's been talk about what we are doing with the converter layer as re-inventing the Atom format. That is debatable. However, Atom is also a popular format we shouldn't ignore. One possible way to support this is to embed our XML or JSON representation as the content to an Atom entry. Again, we will need to have runtime support for this.

Note: We will add more to this section as we discuss more on this.


RDF stands for Resource Description Framework.. It is the basis for Sematic Web. You can learn about it by reading the RDF Primer. If you read up on RDF and RDF/XML in particular, you'll realize that it fits very well with what we are doing, i.e. representing database entities. I am not sure how important this format is for REST but we should keep an eye on this especially that Microsoft's Astoria project also supports it.

Support for Efficiently Retrieving an Entity Given an URI

I want to revisit a feature I requested a while back for the REST runtime. It has to do with retrieving an entity internally given an URI embedded in a XML document. Currently, we have to internally send a GET HTTP request for a given URI to retrieve its XML representation. We then unmarshal the XML representation into a converter instance. From there, we get a copy of the entity instance. Furthermore, we need to merge the copy with the actual instance in the persistence context.This is very convoluted and inefficient. I would to like come up with a more efficient solution to this whether it is in the runtime or the code we generate.

There are a couple of suggestions from Paul:

  • an in process HTTP container that allows one to get access to the 'it' object that an HTTP request would be dispatched to. A possible issue is that the in-process client request may be different from an external client HTTP request and the resource code may require modification to cater for both.
  • support for a URI template class (similar to what MS provide, which IIRC Marc and I discussed before MS announced their API). Given a URI and a URI template one can extract the information from the URI. If you know what object you want to use to get access to the entities then such templates could be used with that object.rren

Support for Client Creation

This is a request from our evangelism team. We currently only have a server-side story. It would have been a even more compelling story if we can support client creation as well. It doesn't have to be fancy like the Visual Web Pack but some form of client libraries that will facilitate creating the client application would be a good start. One possibility is to package up the JavaScript code we've written for the test client (which we reused for creating the JavaOne JeeJay demo.) into a library. We can add support for reading the WADL, DOJO widgets for accessing RESTful services, etc. We might even want to consider generating additional library code based on the generated RESTful services to make it easy for client applications to invoke those services.

Support for Previewing the XML Representation as an Instance Document

This is another idea from the evangelists. The idea is to let users preview the XML representation as an instance document using the existing XML capability in NetBeans. One possible way to support this is to generate the XML schema from the converter classes and use the XML tools to generate the instance documents from the schema.

Support for HTTP Monitor in the Test Client

Even though the IDE supports HTTP monitoring, it is inconvenient for users to have to switch between the browser and the IDE in order to inspect the HTTP messages. There are two possible ways to solve this. One is to run the test client as a Swing application in the IDE. Another possiblities is to embed a HTTP monitor in the current browser-based test client. In fact, Ayub implemented some HTTP monitoring capabilities in the JavaOne DeeJay demo. We should make that available in our test client.

Support for Database Migration

This is a feature we will have to support eventually as JSR 311 and the RI becomes more mature especially since Ruby on Rail supports it. This is a difficult problem for us given that we don't have a framework and Java doesn't have the capability to dynamically modify classes like Rudy. RoR can do this easily because it does not pre-generate methods for accessing the database. Instead, it uses a hack that takes advantage of the fact that Rudy runtime calls a missng-method method when a method being called does not exist. RoR overrides the missing-method method to dynamically generate the missing method. Since there is no pre-generated code, it is easy to support database migration.

Support for Queries in the URIs

Our current generated entity-based resources do not support any form of queries that can limit the results that get returned to the caller. For example, when retrieving a container resource, we would return all the items associated with the container. We currently don't generate any code to let users specify query parameters that would limit the result set.

Microsoft's Astoria project supports this by enclosing a query string in the URI. Furthermore, it support pagination by using query parameters in the URI. For more information, check out the Astoria Online Service.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo