One way I've worked with Atom services within Restlet is to use freemarker templates to generate atom representations and use an XML parser to parse entity bodies of APP POST/PUT requests. This allows me to extract the data I'm interested in without pulling the whole Atom tree into memory as Rome would. A nice side effect of this design is that my resources support con-neg and can also return and process hAtom micro-formatted HTML and JSON (both generated using freemarker as well).
One more note, Atom XML is great to use when you need to support generic APP clients, but if you control both the client and server I'd seriously consider using JSON (while also supporting Atom). JSON tends to push fewer bytes across the wire is infinitely easier to parse in a browser (I'm not an XML hater, but when you need to support IE 6). Dave On Fri, Jul 17, 2009 at 2:00 PM, Tim Peierls<t...@peierls.net> wrote: > Thanks, Stephen, this is very helpful. > --tim > > On Fri, Jul 17, 2009 at 3:01 PM, Stephen Groucutt > <stephen.grouc...@gmail.com> wrote: >> >> I'll qualify this by saying that I know of plans to use APP in enterprise >> applications, but I haven't ever actually seen anything in the enterprise. >> There's a good presentation on APP's capabilities in non-trivial >> environments over at >> http://qconsf.com/sf2007/presentation/Building+your+next+service+with+the+Atom+Publishing+Protocol >> that you might find helpful if you haven't already read it. >> >> To my mind, the thing APP really has going for it in terms of how it >> applies to the REST world is that it is a media type that allows for the >> fulfillment of the "hypermedia as the engine of application state" part of >> Dr. Fielding's thesis. You can use the feeds, the links in the feeds, and >> some microformats you can develop specifically for your program domain, to >> develop APIs. Links can send your clients to the next step of your >> workflows, if the clients understand your microformats. If you google >> around for restbucks, you should find a good presentation on that kind of >> stuff. In theory, it sounds great (but again, I haven't seen it done >> myself). >> >> As to what extensions are best, I was working on Atom stuff back around >> 1.2 milestone 4 or so, and at that time I found it easiest to use ROME to >> offer up feed representations instead of the Restlet Atom extension, so I >> can't say much about what would work best now. >> >> On Fri, Jul 17, 2009 at 2:32 PM, Tim Peierls <t...@peierls.net> wrote: >>> >>> Some rambling newbie Restlet design questions: >>> Background: I'm in the preliminary stages of a ground-up redesign of an >>> existing non-Restlet application. I'm (naturally) convinced that Restlet is >>> the way to go for this redesign, and I'm pretty sure I want the UI to be >>> GWT-based. So far so good ... GWT-Restlet is alive and well. (And I'll get >>> cracking on a Restlet-Guice extension before too long, or not, depending on >>> how you define "too".) >>> My analysis of the existing application keeps leading me to the Atom >>> Publishing Protocol, because the key elements of that application "feel" >>> like collections of publishable/updatable resources (and collections of such >>> collections). It doesn't fit the canonical examples of APP, however, which >>> leads to my first questions: Does anyone know of APP being used successfully >>> outside of the usual document/news item examples that everyone uses to >>> explain it? If so, what criteria would you use to determine whether APP is >>> really appropriate to my resource design? >>> I'm sort of hoping the answer is a resounding yes to this, in which case >>> my second question is: If I want to design my application around APP but I >>> don't intend to use a file-based storage system like eXist, what does >>> Atomojo have for me that the Restlet Atom extension doesn't? Is there >>> something else that I should know about? >>> --tim >> > > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372172
