Hi Al, Thanks for the comments. The book/chapter description is actually a simplification of my real problem domain (which is commercially sensitive).
The under-lying storage mechanism isn't simple but is quite abstract from the REST API we are providing and the hierarchical model is required to describe the relationships between resources in the desired way. If you can get your hands on that O'Reilly book it's worth a read, seems to be one of the better REST resources around. Mike 2008/6/17 Al Sutton <[EMAIL PROTECTED]>: > Mike, > > The safari signup requires a credit card which I'm not going to give so I'm > afraid I can't comment after seeing the book. > > It has always been my understanding that the /Earth/France/Paris style of > notation is a search engine optimised (SEO) layer which has the design goal > of being descriptive to humans and search engines and is not designed with > the REST principals of performance and efficiency. > > The main problem with performance is that, in most cases, you're going to be > looking the data up in a database table, therefore you have your unique ID > as the primary key for the table. The data in the table may, in turn, be a > reference to a storage device and location where the data is stored, but at > the top level you have the single primary key, hence the single /noun/id > combination. > > If you're thinking of mapping the book to a folder name and the chapter to a > filename in the folder then I would urge you to look at some of the comments > around the web on how flat file systems scale, and possibly think about an > intermediate table which maps IDs to the location of the chapter data which > would allow you to have separate file stores to spread the data accross. > > Al. > > Mike Watson wrote: >> >> Thanks for the feedback. >> >> I actually disagree regarding whether my url syntax is restful. >> >> Have you read the O'Reilly book: "RESTful Web Services" by Leonard >> Richardson; Sam Ruby? >> >> If not please take a look (you can probably see sample chapters on >> Safari if you don't have an account). >> Specifically in section 5.5.1 Encode Heirarchy into Path Variables >> where examples like this are provided: >> http://maps.example.com/Earth/France/Paris >> >> In fact the samples the entire book is based on all rely on hierarchy. >> Hierarchy is *very* relevant to my problem domain and is something >> that a RESTful interface *should* be able to support. Do you not agree >> a news website is hierarchical? The web is hierarchical in nature. >> REST is supposed to be the language of the web... >> >> If the REST plugin can't support this hierarchical model I'd say it is >> fundamentally flawed. I'm happy to help rectify this but to say that >> this approach just isn't REST is simply not true. >> >> Can anybody suggest where I would start in an attempt to implement >> this hierarchical model? Or do I need to start looking for a >> replacement for the Struts2 REST plugin? >> >> Thanks for your time. >> >> Mike >> >> 2008/6/17 Al Sutton <[EMAIL PROTECTED]>: >> >>> >>> It's true that it takes a bit of reading between the lines, but basically >>> REST relies on unique identifiers for resources, which for HTTP is >>> commonly >>> taken to mean a URLs of the form; >>> >>> http://server/resource_noun/id >>> >>> (to confirm this have a spin through the google results showing various >>> examples). >>> >>> With servers with many apps on this is commonly expanded to; >>> >>> http://server/app/resource_noun/id >>> >>> In the strictest send the Mikes URLs should be; >>> >>> http://www.mydomain.com/chapter/123_1 >>> >>> because we are uniquely identifying a chapter and to do this we need to >>> include the book id, but for the sake of clarity (which was the reason I >>> beleive he was using x/x_id/y/y_id notation I expanded the noun to show >>> book >>> and chapter. >>> >>> Al. >>> >>> >>> Laurie Harper wrote: >>> >>>> >>>> It may be the case that the REST plugin can't support this (I don't know >>>> if that's true) but I don't see anything in the cited reference that >>>> says >>>> such URLs are un-RESTful. And a Struts apps should certainly be able to >>>> support them, even if it requires writing a little more code (e.g. a >>>> custom >>>> action mapper?) >>>> >>>> L. >>>> >>>> Al Sutton wrote: >>>> >>>>> >>>>> Mike, >>>>> >>>>> Rest URLs doesn't work that way, so the plugin is correct and your >>>>> needs >>>>> are not in sync with REST standards (see >>>>> http://en.wikipedia.org/wiki/Representational_State_Transfer for a more >>>>> details on REST). >>>>> >>>>> If you want to do something with multiple IDs my suggestion would be >>>>> URLs >>>>> along the lines of; >>>>> >>>>> http://www.mydomain.com/rest/bookAndChapter/123_1 >>>>> >>>>> Al. >>>>> >>>>> Mike Watson wrote: >>>>> >>>>>> >>>>>> Hi Folks, >>>>>> >>>>>> I'm trying to use the REST plugin to implement a service that serves >>>>>> resources using the following url syntax: >>>>>> >>>>>> http://www.mydomain.com/rest/book/123 (which works fine) >>>>>> http://www.mydomain.com/rest/book/123/chapter (which throws a 500 >>>>>> because my book controller doesn't have a chapter() method) >>>>>> http://www.mydomain.com/rest/book/123/chapter/1 (which returns 404) >>>>>> >>>>>> I'd expect the two chapter urls to access the ChapterController >>>>>> instead of the BookController. >>>>>> >>>>>> Being able to request resources 'within resources' like this is >>>>>> crucial to my application. Can anybody tell me how I can configure the >>>>>> rest plugin to behave like this, or point me at some documentation >>>>>> that does? >>>>>> >>>>>> Thanks in advance, >>>>>> >>>>>> Mike >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>> >>>>>> >>>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
