On Tue, Jul 21, 2009 at 6:08 AM, Tim Peierls<t...@peierls.net> wrote:
> Hmm, the wind is going out of my sails. I started by recognizing that
> AtomPub seemed to be a natural fit for my domain, and now I'm looking at
> JSON/serialized beans and "optional" plain Atom feeds. (Optional in the
> sense that my main applications wouldn't need them,  because they'd be
> happily talking JSON.)

Interestingly enough, when work first began on the AtomPub spec, there
were some in the working group who were in favor of making the spec
representation agnostic [*]. Even with its concentration on Atom as
its representational format, the App spec for managing collections
provides a pretty clear outline of how to use HTTP effectively for
managing datasets.

[*] One of the AtomPub spec authors clued me in to this a few months ago.

> Anybody have anything encouraging to say about why I shouldn't just stick
> with my existing DWR application? (www.directwebremoting.org)
> --tim

I haven't used DWR in probably 3 years so I'm sure some stuff has
changed but let me enumerate my reasons for preferring a REST

1) REST approach works with the web, RPC works against it. When you
design your service API Restfully you get all the built in benefits of
HTTP such as: cache support, security, scalability, wide client
support, etc. This approach is proven. When using DWR you get none of
these. DWR must push all requests over POST to ensure that no cache
server accidentally caches a result thus breaking your app. Conversely
when using DWR you can't leverage internet caching architecture that
can help offload your servers. Furthermore, a restfully linked set of
resources that support con-neg can support multiple representational
types (such as HTML), thus your API is not just an API but also a
static HTML website that can be indexed by search engines, and allows
for a nice debugging interface in a browser.

2) Strongly defined server interface that is implementation agnostic.
When using DWR, you essentially are exposing your server's Java
methods and tying your client to that implementation. You can't
replace your Java implementation with one in Ruby/C#/fill in the blank
language, later. With the REST approach you are essentially defining
an implementation neutral wire protocol.

3) Strong client/server separation. When using HTTP as your protocol,
you're forced to acknowledge in your client code that you are
accessing a remote resource and take this into account. One of the
major flaws with RPC systems has been the attempt to give remote
resources the appearance of being local, which just doesn't work well
in practice.

4) Multiple client support. DWR only allows you to build your client
in JavaScript (well at least in a well defined way). However, what
happens when your service takes off and you want to support an iPhone
Apps, Android Apps, Desktop widgets, etc. A well defined REST service
may be reused across devices, because it defines a data model with
well understood semantics.

That said, from a software engineering perspective you need to look at
your intended goals for your application and make a sane cost/benefit



Reply via email to