Vincent, > 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).
OK. In the REST/HTTP sense there is only one composite representation here (the page) and one resource (the composite resource represented by the page). But it is also interesting to try to decompose your composite resource/representation, especially if you can display your Orange and Apple resources separately. > We have 3 resources: MainPage, Apple, Orange. Apple and > Orange are what > you call 'low-level' resources'; the Mainpage resource is the highest > abstraction. More or less, it is really a design choice. If you let the user view an Apple resource independently, then is becomes higher-level too. Maybe you will want to have a view resource called ApplePage instead, to keep a strict separation between core reusable resources and view/page resources. > To display the main page you GET /mainPage > What are the apppe's and orange's URI's like? > > For the apple: /mainPage?orange=picture&apple=text > For the orange: /mainPage?orange=text&apple=picture > > Is that what you had in mind? Why not, the URI design is important too, I would probably do: For the apple: /main?orange=picture&apple=text For the orange: /main?orange=text&apple=picture > What if we want to modify the orange? Do we PUT the mainPage, > passing it the Orange info? 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). Best regards, Jerome
