Honestly I'm not sure adding getEntityAsXXXX() anything is a good idea
in the api. I find it confusing that those are there. If anything it
should be a wrapper like DOMEntityConverter.convert(r.getEntity()), or
something like that. That way you can add converters as extensions.
Seems it lends itself to making a getEntityAsXXX() for every type or
have people asking question, like I did with getEntityAsObject(). Maybe
this would also lend itself to adding in extensions for cache
implementations. But in the end, you could easily implement Pico into
your application and call a service on the single request passing in
username and password each time and not even use the Guard. This would
limit to one call to getEntity(). But I may just be talking and not
saying anything. I'm new to REST so you probably know way more about it.
Rob Heittman wrote:
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?
--
Justin Stanczak
Stanczak Group
812-735-3600
"All that is necessary for the triumph of evil is that good men do nothing."
Edmund Burke
