Why do you think DOM or Form does not belong? You should be able to represent resources in any language, markup, or format you want and still follow the REST architectural style. For example, I have a service for interacting with user profile data:
GET .../profile/[EMAIL PROTECTED] retrieves your profile by returning an entity in XML format. PUT .../profile/[EMAIL PROTECTED] can be used to update your profile, by supplying an entity in XML format The XML isn't being used to carry "verbs;" the PUT behavior is idempotent and there are no magical side effects, etc. What you are GETting and PUTting (and/or DELETE-ing and so forth) is an exact and complete representation of the resource at the URL. This all follows the REST architectural style. Although I'm using XML here, I could just as easily support variant representations in JSON format, Java Properties file format, Form (map of property/value pairs) HTML, or whatever else a client might need. Because XML is my default representation language, though, I find it convenient to get the Document representation of the profile; my backing data store speaks Document and this is the easiest possible interaction. Thus getEntityAsDom() is quite helpful to me. If it wasn't there, my application could always parse a String or Stream version of the entity, but it's quite handy syntactic sugar. - Rob ----- Original Message ----- From: "Stanczak Group" <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, August 28, 2007 10:39:13 AM (GMT-0500) America/New_York Subject: Re: Reusable representations I was just looking at another post wondering why DOM is even used in this type of arch. Seems that these two forms should be deprecated as they don't follow the REST paradigm. I also started thinking that in my post about using .getEntityAsObject(). Would all this be better to use a cache system instead of adding it to Restlet? This is why I started looking at the SAX implementation. No matter which way you do it, aren't you adding a Servlet session?
