Posted by joconner
on May 9, 2008 at 2:00 PM PDT
I see themes, three of them, at JavaOne this year: REST, Ruby, and NetBeans
Hundreds of sessions, thousands of people...and what did I come away with? Lots of t-shirts, plush toys, and more t-shirts. Oh, and 3 main things related to my work: REST, Ruby, and NetBeans.
REST -- Want to communicate with web services? You'd better learn something about REST APIs. I can't give a full tutorial here. I hardly know enough myself. But I can give you some info.
- Give everything an id. That id will become part of a URI. Think of your application in terms of resources and URIs that access them.
- Use the standard HTTP vocabulary to act on those resources: GET, POST, PUT, DELETE, and a few others. There's nothing complicated here. GET /customer/1 retrieves infor about customer 1 in the app. POST /customer sends customer information for a new customer. A new id gets generated. PUT /customer/1 updates some information about customer 1. And DELETE /customer/1 removes that object. Simple vocabulary. Use it.
- Provide multiple representations of resources. You can use content negotiation or different URIs to retrieve multiple representations of the same data.
- Use stateless communication. Avoid sessions whenever possible. Put whatever you need to process a request in the URI.
- Finally, use some decent patterns. The container-item pattern is useful. GET /container provides a list of items. POST /container creates a new item in the container.
Some of the benefits of a RESTful architecture on the server side: scaleability, cacheable resources, reduced coupling. On the client side: resources are bookmarkable, you can easily test from a standard browser, you get broad programming language support for REST through standard HTTP, and you can get access to multiple formats for the data depending on your client capabilities and content negotiation.
Ruby -- Lots of sessions talked about Ruby or JRuby . You couldn't escape Ruby. Ruby running on Java, Java from Ruby, Ruby from Java...it's a mixed up, crazy, beautiful combination. And you know the part I really liked. Apparently, once you create your application using Ruby (and Rails of course), you don't have to sound the alarms with your IT department by introducing another server to them. Supposedly, and I haven't tried this yet, you can deploy JRuby on Rails applications as WAR files on a standard Java application server. That's impressive.