Re: Question to all about visual webapps and Restlet
Very interesting discussion indeed. I've been experimenting with building visual REST applications – I used a href=http://www.frevvo.com;frevvo/a and a href=http://www.restlet.org;Restlet/a (I work for frevvo). I've posted a couple of blog articles about my experiences and I'm definitely interested in knowing how other people are building visual web applications with REST. You can find much more including diagrams, examples and source code at: a href=http://www.frevvo.com/blog/?p=26;Visual REST apps: Part 1/a a href=http://www.frevvo.com/blog/?p=32;Visual REST apps: Part 2/a I tend to think in terms of View Resource (forms) that compose Entity Resources (documents). The View Resource can update existing entities, create new ones, store locally or update remotely – all in a uniform RESTful manner. IMO, it's a very powerful and flexible way to interact with the web and create REST applications that handle complex visual elements without compromising REST principles. I'd be very interested in your thoughts. Thx, -Ashish Matthieu Hug wrote: Vincent vincent.lari at yahoo.ca writes: Hi Matthieu, Hello Vincent You'll find comments within the text below. Best regards, Basically I've a rich client application (Flex) accessing Ah, but it's quite a different story, as the final (visual) representation is assembled on the client, not on the server. Absolutly. I considered each resource as being kind of a virtual web page, with one URI and one (or several if required) layouts (representations). The application accesses the required resources, and assembles them for display. So if one page displays A and B, and another page displays A, B, and C, A knows it has two layouts (a/B and A/B/C). If you later add D to the page, you'll add a third layout for A. Is that correct? layout is really misleading, sorry about that: it was meant to relate to restlet's representation (the way the resource is viewed by the client), not to the display within the client. All resources are represented as atom feeds: so the representation (which I wrongly called layout) in restlet sense is this atom feed; then the client displays it as it wishes. So A does not know (and shouldn't IMHO) it can be dispayed with B or with B/C. If D is added later, and it is independent from A and it is only a client issue. An important point is that each resource includes links to all other resources it is logically linked to: the client has absolutly NO knowledge of the links between resources, it virtually navigates between them as needed. If A is linked to A and B, when the client accesses A it receives its representation, including a link to B and a link to C; Let say these resources are independent one of another (For instance if A is a weather report, B a news feed, and C your profile). Who is responsible for linking them together? Does A know it's linked to B and C, or are these associations established at a higher level? If resources are independent there're not linked together. The link must be meaningful in a business sense. There could definitly be a higher level resource that associates independent resources. For instance, let's say that your example relates to a personal mashup, something like google personal page or netvibes. Then you could consider that C contains links to B and A (the user chose B and A among a series of mashups, and its part of his profile), but A and B are not linked together (another user could use A without B). In that case C would stand for the higher level resource. A's representation contains a link to B and C, which means the client has to GET and C, and pass their representation to the template in order to generate the page. So, do B and C's representations contain links to A? The client indeed navigates through the resources and the links provided in their representation exactly like a human would navigate through web pages: it has no other knowledge than the links provided by resources (no resource can be accessed if it is not linked by a previously loaded resource). Then it is not mandatory to have symmetric links. Resources are really analoguous to web pages: many pages have links to Amazon, but Amazon does not have symmetric links to all of them. However until now symmetric links proved to be useful to navigate between resources of the application. -vincent.
Re: Question to all about visual webapps and Restlet
On 4/11/07, Vincent [EMAIL PROTECTED] wrote: [...] I think it's helpful to think in terms of fundamental, base resources and composite, view resources. [...] For other cases, I think it makes more sense to have the facets more or less completely disjoint. The human useful, composite views may make a lot more sense to the user if they have their own naming hierarchy, etc. and just use the various, lower-level resources as services, if you will, that are managed separately. Are you saying views should be first-class resources. and GET 'lower-level' resources to assemble the page? If yes, what's the need for the lower-level resources? The ForumView resource would just retrieve the object it needs from the DB (profile and post in Jeff's example), inject them in the template and return the template's result. If the lower level resources are all completely captive to a single server then there's arguably no benefit. However, it makes things a lot easier to horizontally and vertically partition and otherwise scale the system. For example, what happens when the lower level resource starts dominating the run-time? If it's already a clearly defined and easily identified resource then it should be trivially easy to move it to another server. Hope this helps, John
Re: Question to all about visual webapps and Restlet
On 4/12/07, Jerome Louvel [EMAIL PROTECTED] wrote: [...] What is essential is that your core domain model is well defined and reused by all your view resources. This core domain model can also be distributed and implemented as RESTful resource if you can afford this flexibility. FWIW, I think people use performance as an excuse to not model their systems this way to begin with. Indeed, the flexibility can help improve performance. I've been thinking a lot about this too, and I came to the conclusion that the best way to put a face on a restfull app is the have the client -not the server- assemble the view. The simplest (an ugliest) way is to use frames; a better solution is to make Ajax calls to the server to retrieve individual resources, and insert the returned html (or xml, json, etc) in the page. It also scales better if the application is stateless (no need to retrieve the profile each time we display a post). Of course, this is valid only for relatively complex application(e.g. a webmail client). But if your application is restul and your UI moderately complex, it calls for a single-page UI (a la GWT) as opposed as the standard multi-page design. My concern with those approaches (AJAX) is that they somewhat break the hyperlink design of the Web, and the ability to bookmark each state of your application. Well, our application (krugle.com) is a pretty hardcore AJAX application. In terms of Vincent's points, AJAX is a perfectly reasonable solution (but has other tradeoffs). It's certainly possible to support both a clean, pure page approach as well as an AJAX client. This is where having a multiple views approach can really payoff big (especially when you think about also having a public api :-). Supporting bookmarkable URLs in AJAX applications is more of a UI issue than a technical one. Back button support is a much more painful topic. :-) Take care, John
RE: Question to all about visual webapps and Restlet
Hi Vincent, You add a query parameter with an URI to return to after edition: /orange/editor?return=/main?orange=pictureapple=text But maybe the page you return to depends on the result of the operation. It's not a decision the client can make. Ok, in this case your /orange/editor resource can issue a redirect to the target URI dynamically generated. The orange never includes the apples, only the main page resource does include both of them. To make sure we are on the same page, do you agree that the following URIs identify different resources? - /main - /main?orange=picture - /main?orange=pictureapple=text - /main?orange=pictureapple=picture Actually, I don't. To me they all identify the main page, in different states. Would not that be like saying: /document/123;font=large /document/123;font=small identify 2 resources? Exactly, each time you change the URI, even to simply add a query parameter, you create a different identifier. This new identifier correspond to a different target resource! Why would you diffentiate /document/123;font=large from /document/123/large? From the REST/HTTP point of view, two different URIs identify two different resources. Now, at the Restlet level, you can perfectly reuse the same Resource subclass for all similar target resources, but each instance of the class will be corresponding to a different target resource. Best regards, Jerome
Re: Question to all about visual webapps and Restlet
Vincent vincent.lari at yahoo.ca writes: Hi Matthieu, Hello Vincent You'll find comments within the text below. Best regards, Basically I've a rich client application (Flex) accessing Ah, but it's quite a different story, as the final (visual) representation is assembled on the client, not on the server. Absolutly. I considered each resource as being kind of a virtual web page, with one URI and one (or several if required) layouts (representations). The application accesses the required resources, and assembles them for display. So if one page displays A and B, and another page displays A, B, and C, A knows it has two layouts (a/B and A/B/C). If you later add D to the page, you'll add a third layout for A. Is that correct? layout is really misleading, sorry about that: it was meant to relate to restlet's representation (the way the resource is viewed by the client), not to the display within the client. All resources are represented as atom feeds: so the representation (which I wrongly called layout) in restlet sense is this atom feed; then the client displays it as it wishes. So A does not know (and shouldn't IMHO) it can be dispayed with B or with B/C. If D is added later, and it is independent from A and it is only a client issue. An important point is that each resource includes links to all other resources it is logically linked to: the client has absolutly NO knowledge of the links between resources, it virtually navigates between them as needed. If A is linked to A and B, when the client accesses A it receives its representation, including a link to B and a link to C; Let say these resources are independent one of another (For instance if A is a weather report, B a news feed, and C your profile). Who is responsible for linking them together? Does A know it's linked to B and C, or are these associations established at a higher level? If resources are independent there're not linked together. The link must be meaningful in a business sense. There could definitly be a higher level resource that associates independent resources. For instance, let's say that your example relates to a personal mashup, something like google personal page or netvibes. Then you could consider that C contains links to B and A (the user chose B and A among a series of mashups, and its part of his profile), but A and B are not linked together (another user could use A without B). In that case C would stand for the higher level resource. A's representation contains a link to B and C, which means the client has to GET and C, and pass their representation to the template in order to generate the page. So, do B and C's representations contain links to A? The client indeed navigates through the resources and the links provided in their representation exactly like a human would navigate through web pages: it has no other knowledge than the links provided by resources (no resource can be accessed if it is not linked by a previously loaded resource). Then it is not mandatory to have symmetric links. Resources are really analoguous to web pages: many pages have links to Amazon, but Amazon does not have symmetric links to all of them. However until now symmetric links proved to be useful to navigate between resources of the application. -vincent.
RE: Question to all about visual webapps and Restlet
Hi Vincent, No it wouldn't make sense. You would instead directly modify the Orange resource, either directly from the browser or via some edition pages (to allow multi-page edition for example). But then how you return to the main page after you've modified the orange? You add a query parameter with an URI to return to after edition: /orange/editor?return=/main?orange=pictureapple=text Now we're saying that the orange needs not be aware of the apple (the links are managed at a higher level (the main page)); Yes, unless there was a natural link between oranges and apples, which is not the case here. So what does the PUT operation return? A description of the orange? It's not what we need. a /main?orange=pictureapple=text uri? But how does the orange know it has to include the apple? The orange never includes the apples, only the main page resource does include both of them. To make sure we are on the same page, do you agree that the following URIs identify different resources? - /main - /main?orange=picture - /main?orange=pictureapple=text - /main?orange=pictureapple=picture Best regards, Jerome
Re: Question to all about visual webapps and Restlet
Hi Matthieu, Basically I've a rich client application (Flex) accessing Ah, but it's quite a different story, as the final (visual) representation is assembled on the client, not on the server. I considered each resource as being kind of a virtual web page, with one URI and one (or several if required) layouts (representations). The application accesses the required resources, and assembles them for display. So if one page displays A and B, and another page displays A, B, and C, A knows it has two layouts (a/B and A/B/C). If you later add D to the page, you'll add a third layout for A. Is that correct? An important point is that each resource includes links to all other resources it is logically linked to: the client has absolutly NO knowledge of the links between resources, it virtually navigates between them as needed. If A is linked to A and B, when the client accesses A it receives its representation, including a link to B and a link to C; Let say these resources are independent one of another (For instance if A is a weather report, B a news feed, and C your profile). Who is responsible for linking them together? Does A know it's linked to B and C, or are these associations established at a higher level? A's representation contains a link to B and C, which means the client has to GET and C, and pass their representation to the template in order to generate the page. So, do B and C's representations contain links to A? -vincent.
Re: Question to all about visual webapps and Restlet
John, I think it's helpful to think in terms of fundamental, base resources and composite, view resources. [...] For other cases, I think it makes more sense to have the facets more or less completely disjoint. The human useful, composite views may make a lot more sense to the user if they have their own naming hierarchy, etc. and just use the various, lower-level resources as services, if you will, that are managed separately. Are you saying views should be first-class resources. and GET 'lower-level' resources to assemble the page? If yes, what's the need for the lower-level resources? The ForumView resource would just retrieve the object it needs from the DB (profile and post in Jeff's example), inject them in the template and return the template's result. -vincent.
RE: Question to all about visual webapps and Restlet
Hi John, [...] I think it's helpful to think in terms of fundamental, base resources and composite, view resources. An analogy is the difference between tables and views in a relational database such as Oracle. I agree, this is a useful analogy. As you noted, in your example, it could be modelled where the same URL is used but the two facets are distinguished by whether the caller asks for the base (e.g., application/xml) or a human version (e.g., xhtml). For other cases, I think it makes more sense to have the facets more or less completely disjoint. The human useful, composite views may make a lot more sense to the user if they have their own naming hierarchy, etc. and just use the various, lower-level resources as services, if you will, that are managed separately. I agree and would add that those lower-level resources (or core resources) could be modelled and exposed as either: - persistent POJOs (db4o, EJB3, etc.) - RESTful resources (via a separate Restlet application for example) In the second case, you could even think about a two-layer approach, where on Web Component would remotely access to an internal Core/Business Component. This way, your Core Component could be shared between several 'view' applications/components. Best regards, Jerome
RE: Question to all about visual webapps and Restlet
Hi Vincent, So you're forcing one resource to be aware of other resources just because of the way your user interface in designed. If you switch to HTML frames, you no longer need these dependencies because each frame displays only one resource (the content frame, the profile frame, the navigation frame, etc.). Yes, in this case the resource is a view resource. The addition of frames wouldn't break the design, the Web representation would just remove the contextual information (sidebar, etc.) and we would add new dedicated resources for the other frames. And what about cross references? If you click on a post in one of the thread, the 'post' resource must know about the 'profile' resource because it's part of its 'contextual information'. Now let's say you have a 'More' link in the profile section to display more of your profile info. In order to redisplay the page, the 'profile' resource will have to know about the 'post' resource too (because when you GET /profile/123;details, you need to include the current post). Imagine the graph (and the resulting maintenance nightmare) if you have 5 resources displayed on one page. I'm not sure to follow you precisely, but for sure a Web page is a representation of a single target resource. It doesn't matter how many sub-resources or domain objects were used to build this representation. And what if the same resource can be displayed in several type of views? Take this forum, for instance: When you a click on a thread, the post is displayed in the bottom part of the screen. You can also click on the direct-link and have the post displayed on a new page (without the threads). gmane uses frames to achieve this, but how would you do it without frames? Include the view in the url? GET http://article.gmane.org/gmane.comp.java.restlet/1871;view=threaded GET http://article.gmane.org/gmane.comp.java.restlet/1871;view=single Or you could decide that what you're viewing is the form, and the uri becomes: GET http://article.gmane.org/gmane.comp.java.restlet?activeView=1871 The danger with this approach is that it forces you to think in terms of pages (the forum, the main page, etc.) instead of resources. Or more exactly: your pages become your resources. Exactly, and their is nothing fundamentaly wrong with this. What is important is that you don't create unnecessary page resources. As soon as you add a ?page=2 query parameter, you identify a resource that is separate from the one identified by ?page=3. There is nothing you can do against this. What is essential is that your core domain model is well defined and reused by all your view resources. This core domain model can also be distributed and implemented as RESTful resource if you can afford this flexibility. I've been thinking a lot about this too, and I came to the conclusion that the best way to put a face on a restfull app is the have the client -not the server- assemble the view. The simplest (an ugliest) way is to use frames; a better solution is to make Ajax calls to the server to retrieve individual resources, and insert the returned html (or xml, json, etc) in the page. It also scales better if the application is stateless (no need to retrieve the profile each time we display a post). Of course, this is valid only for relatively complex application(e.g. a webmail client). But if your application is restul and your UI moderately complex, it calls for a single-page UI (a la GWT) as opposed as the standard multi-page design. My concern with those approaches (AJAX) is that they somewhat break the hyperlink design of the Web, and the ability to bookmark each state of your application. Best regards, Jerome
Re: Question to all about visual webapps and Restlet
I agree and would add that those lower-level resources (or core resources) could be modelled and exposed as either: - persistent POJOs (db4o, EJB3, etc.) - RESTful resources (via a separate Restlet application for example) In the second case, you could even think about a two-layer approach, where on Web Component would remotely access to an internal Core/Business Component. This way, your Core Component could be shared between several 'view' applications/components. So, say we have a page that displays a picture of an apple and a picture of an orange. When we click on either picture, we want to replace it by the text representation of the selected fruit (we we want to keep displaying the picture of the other fruit). We have 3 resources: MainPage, Apple, Orange. Apple and Orange are what you call 'low-level' resources'; the Mainpage resource is the highest abstraction. To display the main page you GET /mainPage What are the apppe's and orange's URI's like? For the apple: /mainPage?orange=pictureapple=text For the orange: /mainPage?orange=textapple=picture Is that what you had in mind? What if we want to modify the orange? Do we PUT the mainPage, passing it the Orange info? -vincent.
RE: Question to all about visual webapps and Restlet
Hi Jeff, This is an interesting question and I'm also curious to see how others handle this case. To me, it seems fine if the Web representation of the resource thread number 3 of the help forum contains navigation data and other contextual help. This is just how you represent your resource on a Web page. The same resource could expose a more focus XML representation for programmatic clients. Now, in term of coding, your ThreadResource class should have access to all the domain objects (POJOs) required to return the Web representation: Thread, User, Connections, etc. Best regards, Jerome -Message d'origine- De : Jeff Walter [mailto:[EMAIL PROTECTED] Envoyé : mercredi 11 avril 2007 06:19 À : discuss@restlet.tigris.org Objet : Question to all about visual webapps and Restlet Hey All, Little philosophical/architectural question here... I'd like to know how many other people are using Restlet to build visual web applications, and how they feel about aggregating resource data on their pages? Let's take a simple example: We have a Resource for a thread on a forum: http://somesite.org/forums/helpforum/threads/3 On this page, we display the thread Resource, but we also want to show in a sidebar, lets say other online users browsing the help forum, and the latest 3 posts to the help forum (the actual data is unimportant, but the fact that the data is not a part of the single thread Resource is). In Restlet, accessing this URL would load up a Thread Resource and pick its HTML representation (let's say using a Freemarker template). To display the extraneous data in the sidebar, the Thread resource is going to have to access other Resources information to then pass to the template. Additionally, if this forum requires that a user be logged-in to participate in discussions, the header on the page might contain a logout link if the user is logged in (or login link if they weren't already logged-in). Having extraneous information on a web page is pretty common requirement, but it seems to not feel right to me in terms of Resource implementation in Restlet. How do people feel about Resources loading the extra Resource data to feed to the templates? Is this just par for the course and necessary? Are there best practices people like to employ to accomplish this without feeling like you are defeating the nice separation of Resources the framework creates for you? Any thoughts would be appreciated... just wanted to hear some ideas/start a discussion. Thanks! Jeff
Re: Question to all about visual webapps and Restlet
On 4/10/07, Jeff Walter [EMAIL PROTECTED] wrote: [...] I'd like to know how many other people are using Restlet to build visual web applications, and how they feel about aggregating resource data on their pages? What do you mean by visual web applications? I'm going to presume that you mean for consumption by humans as opposed to use as e.g. a programmatically accessible API. Let's take a simple example: We have a Resource for a thread on a forum: http://somesite.org/forums/helpforum/threads/3 On this page, we display the thread Resource, but we also want to show in a sidebar, lets say other online users browsing the help forum, and the latest 3 posts to the help forum (the actual data is unimportant, but the fact that the data is not a part of the single thread Resource is). In Restlet, accessing this URL would load up a Thread Resource and pick its HTML representation (let's say using a Freemarker template). To display the extraneous data in the sidebar, the Thread resource is going to have to access other Resources information to then pass to the template. Additionally, if this forum requires that a user be logged-in to participate in discussions, the header on the page might contain a logout link if the user is logged in (or login link if they weren't already logged-in). Having extraneous information on a web page is pretty common requirement, but it seems to not feel right to me in terms of Resource implementation in Restlet. How do people feel about Resources loading the extra Resource data to feed to the templates? Is this just par for the course and necessary? Are there best practices people like to employ to accomplish this without feeling like you are defeating the nice separation of Resources the framework creates for you? I think it's helpful to think in terms of fundamental, base resources and composite, view resources. An analogy is the difference between tables and views in a relational database such as Oracle. As you noted, in your example, it could be modelled where the same URL is used but the two facets are distinguished by whether the caller asks for the base (e.g., application/xml) or a human version (e.g., xhtml). For other cases, I think it makes more sense to have the facets more or less completely disjoint. The human useful, composite views may make a lot more sense to the user if they have their own naming hierarchy, etc. and just use the various, lower-level resources as services, if you will, that are managed separately. Hope this helps, John
