I'm wondering about these 3 issues. Would love to know what other folks think about it
1) the easiest way to approach/demonstrate REST. Assuming someone has built a few webapps using java. Say, this developer/manager has worked with servlets and JSPs (and possibly Struts), what is the easiest way to get this developer to starting using REST architecture ?
2) Intranet apps and rest : There are a lot more intranet apps than internet apps. Are there any differences in the way REST can be used/implemented in intranet apps ? Many of the intranet/extranet apps use highly specific "TYPE" content in the information that is exchanged.
3) java/j2ee frameworks that help in the REST way of life. In 2007, atleast half of the J2EE world is either using one of the web frameworks (like Struts(2), Webwork, Spring, Wicket, etc) to build webapps. Is there an easy way to bolt REST on top of these frameworks ? I know that Rails is putting a lot of emphasis on REST. What is the direction from the java/j2ee frameworks ?
Joined: Dec 18, 2006
I should have added (forgot to) another question
4) Can you choose one of the implementations of PetStore(the Java/J2EE petstore, Spring petstore, iBatis PetStore) and make it restful so that people can quickly see the difference ? This would enable people who understand the Petstore example how to implement REST in a practical way.
I have put up a very rushed record of my attempt to design a RESTful pet store application. It ought not be emulated, but hopefully it shows you how the same functionality can be exposed in RESTful or unRESTful ways.
> 1) the easiest way to approach/demonstrate REST. > Assuming someone has built a few webapps using java. Say, this > developer/manager has worked with > servlets and JSPs (and possibly Struts), what is the easiest way to get this
imho, a servlet/JSP developer could get started having fun with REST by:
1. Building a REST *Client*
Eg, write something in your favourite language which consumes the Amazon/Delicious/Flickr API (and perhaps transforms it into something your manager will like - eg HTML)
2. Building read-only REST *Service*, for one of your existing applications.
Eg write a Servlet which responds to GET requests for http://foo by returning an XML representation of foo. Choose a Foo that you are familiar with (eg, Book, Customer Account, whatever you have in your database). Choose an XML represntation of Foo that makes common sense. Spit out the XML. Show XML in Browser to manager.
2. Building read-only REST *Service*, for one of your existing applications. Eg write a Servlet which responds to GET requests for http://foo by returning an XML representation of foo.
But don't get too hung up on the use of XML. REST does not by any means imply XML.
The key point for me about a request GET service (apart from the REST bits about attaching it to a consistent and repeatable URL) is that it returns its data in a consistent and repeatable format.
That format may be XML, but it may equally well be JSON, properties file format, Tract format (a bunch of headers, a blank line, then a text body, as used for HTTP, email, etc.), CSV, or anything else which suits the application.