Re: Guidance on Atom/APP in Restlet
Sorry to jump in so late on this thread... On Fri, Jul 17, 2009 at 11:32 AM, Tim Peierlst...@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 use the APP for all kinds of applications. I use it as a basic storage and retrieval mechanism. Of course, I use a lot of advanced features found inside Atomojo for querying feeds and that is most certainly outside of the APP as a protocol. 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? I think you are a bit confused about what Atomojo has to offer. First of all, there is a server that supports the APP and provides different storage mechanisms. There are currently two storage mechanisms: files and the eXist XML database. I've considered writing an Amazon S3 storage back end but I haven't quite gotten to it yet. Basically, storage is something that you can change in the server. The server itself maintains an index and supports different kinds of metadata and query services independent of the storage used. You can use these services to build applications--which is what I do. Atomojo also provides: * a Java client for interacting with the APP * a Javascript client for doing the same * a web server component that uses configures itself using atom feeds (a special wrap-up of Restlet) * some other application components for building web applications. Much of this still needs documentation. :( --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2379543
RE: Guidance on Atom/APP in Restlet
Hi Tim, Using an object serialization representation does reintroduce strong coupling between a REST client and server. It should only be done for optimization purpose, as an alternative to more reusable and interoperable JSON / XML representations. But wait! XML and JSON do introduce coupling as you need to know their structure in advance most of the time! If you want an even less coupling, then looking towards RDF is a good idea but still you will need to understand some ontologies... With REST/HTTP you can deal with this issue in two ways: - standard representation formats such as HTML, Atom (to a certain extent), PNG, etc. - content negotiation Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com De : tpeie...@gmail.com [mailto:tpeie...@gmail.com] De la part de Tim Peierls Envoyé : mardi 21 juillet 2009 15:08 À : discuss@restlet.tigris.org Objet : Re: Guidance on Atom/APP in Restlet On Tue, Jul 21, 2009 at 4:39 AM, Jerome Louvel jerome.lou...@noelios.com wrote: However, for communication with GWT, it is indeed a better idea to rely on JSON. I have also been working on reusing the 'transparent' serialization of beans between Restlet/Server and Restlet/GWT. This serialization is used in GWT-RPC but can be reused in a RESTful way. This isn't quite ready yet, but hopefully for Restlet 2.0 M4, I'll have something more stable. I've already said that this is very cool, but it does make we wonder ... Isn't this sort of, um, cheating? A representation that is coupled to a particular client/service pair? Another few steps over the edge and we're back to RPC-style services. I guess the saving grace is that Restlet makes it easy, or even trivial, to provide other representations in addition to the one that's optimized for common use, and RPC-style frameworks can't offer that at all. As David mentioned, this could be complementary to exposing Atom representations of your resources. Finally, I'm not sure if you need to support the full AtomPub standard or just the Atom XML one. 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.) Anybody have anything encouraging to say about why I shouldn't just stick with my existing DWR application? (www.directwebremoting.org) --tim -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2375490
Re: Guidance on Atom/APP in Restlet
All valid points. There must be cooperation between a client and server at some level! I have two problems with RPC style implementations on the Web: 1) The RPC paradigm hides the advanced properties of the Web and makes them really difficult to leverage 2) The RPC protocol and serialization behavior is totally opaque to any client or server not using a compatible RPC library, of which (as in GWT) there is usually only one, in one language. Jerome's proposed use of the GWT RPC serialization works around both of these objections. Objection #1 goes away because the serialized representations are exposed using Restlet. Objection #2 goes away for two reasons: a) (weak) The GWT RPC serialization is not really very opaque (compared to, say RMI tunnelled over HTTP). It's JSON and, while terse, not beyond comprehension. I have actually written stuff to do GWT RPC server interop with non-GWT clients, and it's possible, if yucky. b) (strong) Restlet makes it trivial to expose alternate variants (e.g. XML, HTML) for other clients, which you just can't do with RPC alone. So I'm signed up for the serialization train. - R On Sat, Jul 25, 2009 at 5:44 AM, Jerome Louvel jerome.lou...@noelios.comwrote: But wait! XML and JSON do introduce coupling as you need to know their structure in advance most of the time! If you want an even less coupling, then looking towards RDF is a good idea but still you will need to understand some ontologies... -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2375529
Re: Guidance on Atom/APP in Restlet
Hi Tim, The biggest APP user I know is Google, with practically all of its API using the Google Data (GData) protocol. It's basically a extended version of APP, most due to practicality reasons prevailing over idealistic (i.e. pure APP). GData puts some extensive stress testing on APP, i.e. Using advanced features such as querying and returning different serialization formats not just Atom+XML, but manages to adhere to fundamental principles of APP. Aside from Google's own proprietary auth mechanism (which I think can be replaced with Oauth for general masses), I think Google's use of GData/APP is a good example of APP in the real world. On 7/18/09, 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=4447dsMessageId=2372142 -- Sent from my mobile device Best regards, Hendy Irawan http://www.hendyirawan.com/ :: he...@soluvas.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372637
RE: Guidance on Atom/APP in Restlet
Hi Henry, I was about to answer the same thing. In addition to Google, Microsoft is making a heavy use of Atom as well in its ADO.NET Data Services (ex-Astoria) technology: Overview: ADO.NET Data Services http://msdn.microsoft.com/en-us/data/bb931106.aspx?ppud=4 However, for communication with GWT, it is indeed a better idea to rely on JSON. I have also been working on reusing the 'transparent' serialization of beans between Restlet/Server and Restlet/GWT. This serialization is used in GWT-RPC but can be reused in a RESTful way. This isn't quite ready yet, but hopefully for Restlet 2.0 M4, I'll have something more stable. As David mentioned, this could be complementary to exposing Atom representations of your resources. Finally, I'm not sure if you need to support the full AtomPub standard or just the Atom XML one. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Hendy Irawan [mailto:he...@soluvas.com] Envoyé : lundi 20 juillet 2009 17:54 À : discuss@restlet.tigris.org Objet : Re: Guidance on Atom/APP in Restlet Hi Tim, The biggest APP user I know is Google, with practically all of its API using the Google Data (GData) protocol. It's basically a extended version of APP, most due to practicality reasons prevailing over idealistic (i.e. pure APP). GData puts some extensive stress testing on APP, i.e. Using advanced features such as querying and returning different serialization formats not just Atom+XML, but manages to adhere to fundamental principles of APP. Aside from Google's own proprietary auth mechanism (which I think can be replaced with Oauth for general masses), I think Google's use of GData/APP is a good example of APP in the real world. On 7/18/09, 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=4447dsMessageId=23721 42 -- Sent from my mobile device Best regards, Hendy Irawan http://www.hendyirawan.com/ :: he...@soluvas.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23726 37 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372850
Re: Guidance on Atom/APP in Restlet
Thanks -- I was particularly interested in the Google Calendar Data API, but I'd be rolling my own implementation, right? --tim On Mon, Jul 20, 2009 at 11:53 AM, Hendy Irawan he...@soluvas.com wrote: Hi Tim, The biggest APP user I know is Google, with practically all of its API using the Google Data (GData) protocol. It's basically a extended version of APP, most due to practicality reasons prevailing over idealistic (i.e. pure APP). GData puts some extensive stress testing on APP, i.e. Using advanced features such as querying and returning different serialization formats not just Atom+XML, but manages to adhere to fundamental principles of APP. Aside from Google's own proprietary auth mechanism (which I think can be replaced with Oauth for general masses), I think Google's use of GData/APP is a good example of APP in the real world. On 7/18/09, 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=4447dsMessageId=2372142 -- Sent from my mobile device Best regards, Hendy Irawan http://www.hendyirawan.com/ :: he...@soluvas.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372637 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372938
Re: Guidance on Atom/APP in Restlet
On Tue, Jul 21, 2009 at 4:39 AM, Jerome Louvel jerome.lou...@noelios.comwrote: However, for communication with GWT, it is indeed a better idea to rely on JSON. I have also been working on reusing the 'transparent' serialization of beans between Restlet/Server and Restlet/GWT. This serialization is used in GWT-RPC but can be reused in a RESTful way. This isn't quite ready yet, but hopefully for Restlet 2.0 M4, I'll have something more stable. I've already said that this is very cool, but it does make we wonder ... Isn't this sort of, um, cheating? A representation that is coupled to a particular client/service pair? Another few steps over the edge and we're back to RPC-style services. I guess the saving grace is that Restlet makes it easy, or even trivial, to provide other representations in addition to the one that's optimized for common use, and RPC-style frameworks can't offer that at all. As David mentioned, this could be complementary to exposing Atom representations of your resources. Finally, I'm not sure if you need to support the full AtomPub standard or just the Atom XML one. 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.) Anybody have anything encouraging to say about why I shouldn't just stick with my existing DWR application? (www.directwebremoting.org) --tim -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372950
Re: Guidance on Atom/APP in Restlet
Do the Java Client libraries for the Google Data APIs run under GWT? I can't find any indication one way or the other. It'd be cool if they did, though. --tim On Tue, Jul 21, 2009 at 8:29 AM, Tim Peierls t...@peierls.net wrote: Thanks -- I was particularly interested in the Google Calendar Data API, but I'd be rolling my own implementation, right? --tim On Mon, Jul 20, 2009 at 11:53 AM, Hendy Irawan he...@soluvas.com wrote: Hi Tim, The biggest APP user I know is Google, with practically all of its API using the Google Data (GData) protocol. It's basically a extended version of APP, most due to practicality reasons prevailing over idealistic (i.e. pure APP). GData puts some extensive stress testing on APP, i.e. Using advanced features such as querying and returning different serialization formats not just Atom+XML, but manages to adhere to fundamental principles of APP. Aside from Google's own proprietary auth mechanism (which I think can be replaced with Oauth for general masses), I think Google's use of GData/APP is a good example of APP in the real world. On 7/18/09, 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=4447dsMessageId=2372142 -- Sent from my mobile device Best regards, Hendy Irawan http://www.hendyirawan.com/ :: he...@soluvas.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372637 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372967
Re: Guidance on Atom/APP in Restlet
On Tue, Jul 21, 2009 at 6:08 AM, Tim Peierlst...@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=4447dsMessageId=2373212
Re: Guidance on Atom/APP in Restlet
Thanks, Dave. I was going to ask about hAtom, templating engines, and JSON in follow-up questions, but now I don't need to! --tim On Fri, Jul 17, 2009 at 6:16 PM, David Bordoley bordo...@gmail.com wrote: 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 Peierlst...@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=4447dsMessageId=2372172 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372601
Re: Guidance on Atom/APP in Restlet
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+Protocolthat 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=4447dsMessageId=2372149
Re: Guidance on Atom/APP in Restlet
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+Protocolthat 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=4447dsMessageId=2372163
Re: Guidance on Atom/APP in Restlet
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 Peierlst...@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=4447dsMessageId=2372172
