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 approach: 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 analysis. Dave ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2373212
