Re: REST plugin URL syntax
Mike Watson wrote: BTW, if I want a controller to work in multiple namespaces do I need to declare seperate packages in struts.xml instead of just relying on the @Namespace annotation? Thanks again for all your help. Unfortunately when using Codeheind, you do have to create a new package for each namespace. The easiest way to do that is to extend your action and add a @Namespace for each subclass. It's wasteful but works. The Convention Plugin that (eventually) supersedes Codeheind does include a @Namespaces() annotation. Glad I could help! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST plugin URL syntax
Jeromy, Thanks *heaps* for finfing the time to do that. I'd pretty much done everything your demo does except for one little detail: Doh! Now to see if that's broken my fancy pants image handler... BTW, if I want a controller to work in multiple namespaces do I need to declare seperate packages in struts.xml instead of just relying on the @Namespace annotation? Thanks again for all your help. 2008/7/12 Jeromy Evans <[EMAIL PROTECTED]>: > Jeromy Evans wrote: >> >> >> Dusty, you're right. I just had a quick look and I do have a custom action >> mapper that checks whether the pattern above references an action or method >> for that exact reason (it checks the list of available actions and gives >> precedence to those). Works great for me. >> >> I released another actionmapper that solved the problem using a different >> approach. It will be deprecated, but it's still up for info: >> http://code.google.com/p/struts2urlplugin/ > > I had an opportunity to throw together a sample application. Apologies for > the delay. > > Relevant source and commentary are included in the demo. > http://www.blueskyminds.com.au/url-hierarchy/ > > From the description: > "This webapp demonstrates a technique to access resources with hierarchical > relationships in Struts 2. > > The model is a Book with a list of Chapters. Each Book has a unique URI: > eg. /book/1 (book #1) > > Each chapter also has a unique URI: > eg. /book/1/chapter/2 (chapter #2 in book #1) > > Following Struts2 conventions, the list of books and list of chapters in a > book are also available: > eg. /book (list of books) > eg. /book/1/chapter (list of chapters in book #1) > > regards, > Jeromy Evans > > > > - > 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]
Re: REST plugin URL syntax
Jeromy Evans wrote: Dusty, you're right. I just had a quick look and I do have a custom action mapper that checks whether the pattern above references an action or method for that exact reason (it checks the list of available actions and gives precedence to those). Works great for me. I released another actionmapper that solved the problem using a different approach. It will be deprecated, but it's still up for info: http://code.google.com/p/struts2urlplugin/ I had an opportunity to throw together a sample application. Apologies for the delay. Relevant source and commentary are included in the demo. http://www.blueskyminds.com.au/url-hierarchy/ From the description: "This webapp demonstrates a technique to access resources with hierarchical relationships in Struts 2. The model is a Book with a list of Chapters. Each Book has a unique URI: eg. /book/1 (book #1) Each chapter also has a unique URI: eg. /book/1/chapter/2 (chapter #2 in book #1) Following Struts2 conventions, the list of books and list of chapters in a book are also available: eg. /book (list of books) eg. /book/1/chapter (list of chapters in book #1) regards, Jeromy Evans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST plugin URL syntax
http://struts.apache.org/2.x/docs/building-the-framework-from-source.html The instructions are pretty straight-forward. If you've never used maven before, it's a bit tricky at first, but once you run through it a few times, it's pretty easy. If you're building from trunk, then you might want to grab the XWork2 sources and build them as well - http://www.opensymphony.com/xwork/cvs.action -Wes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST plugin URL syntax
--- On Thu, 7/10/08, Mike Watson <[EMAIL PROTECTED]> wrote: > So what's the best way to get the latest 2.1.3 snapshot as source? Via SVN. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST plugin URL syntax
So what's the best way to get the latest 2.1.3 snapshot as source?
Only the jars seem to be in the maven snapshot repo...
Are there any instructions on doing that somewhere? I've looked but
can't find them...
2008/7/3 Jeromy Evans <[EMAIL PROTECTED]>:
> Mike Watson wrote:
>>
>> Hi Jeromy,
>>
>> I've finally found time to try to resolve this but haven't had much luck.
>>
>> Just to recap, I'm looking to be able to do something similar to the
>> following:
>> /book -> returns a list of books
>> /book/123 -> returns book with id 123
>> /book/123/chapter/1 -> return chapter with id 1, retrieved from book
>> 123 (this is a simplistic example, all resources have a unique ID)
>>
>> I'd also like to be able to control access based on the
>> context/namespace used to access a resource e.g.:
>> /logo/abc -> read or update
>> /book/123/logo/abc -> read only
>> (would I need multiple LogoControllers for this?)
>>
>> Using Namespaces as described by Jeromy below certainly seems to make
>> sense but as soon as I start to try the example provided I lose the
>> ability to GET /book/123, and I've tried with BookController having
>> namespace of "/" or "/book" and neither works. And so far I haven't
>> been able to successfully hit the ChapterController using a url like
>> /book/123/chapter.
>>
>> Am I missing something really obvious? Is there something I need to
>> put in the struts.xml to configure the namespaces as well as using the
>> @Namespace annotation?
>>
>> Jeromy, you seem to be pretty knowledgeable about this - can you think
>> of anything I might be doing wrong?
>>
>> Thanks in advance for your help.
>>
>> Mike
>>
>>
>
> Hi Mike, I'll throw a quick answer together now and try to give you a more
> in-depth one in a day or two by building an example.
> The steps are:
> 1. ensure struts is up-to-date. (2.1.3-SNAPSHOT preferably, to ensure you
> have the latest ActionMappingParamsInterceptor)
> 2. enable the NamedVariablePatternMatcher via struts.xml 3. Create the
> BookController in the root namespace. GET /book/123 will invoke
> BookController.show() with id=123
> 4. Create the ChapterController in the namespace containing the book id
> variable (/book/{bookid}). GET /book/123/chapter will invoke
> ChapterContoller.index() with bookId=123.
>
> ie.
>
> @Namespace("/")
> public class BookController implements ModelDriven { }
>
>
> @Namespace("/book/{bookId}")
> public class ChapterController implements ModelDriven { }
>
>
> Now that's what *should* happen. I use it in a large application that
> includes many other related tweaks so I'll throw together a vanilla sample
> and post it somewhere.
>
> I'll come back to the authorization issue separately. The quick answer is
> that you can omit methods that are never permitted and/or filter URLs based
> on a URI pattern and/or user's role.
> regards,
> Jeromy Evans
>
>
> -
> 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]
Re: REST plugin URL syntax
Mike Watson wrote: The trick (I believe) is that the url should be parsed from right to left, not left to right. I don't think it's a hijack; for the application I'm working on context is very important so knowing that a given resource is being accessed in the context of another resource has a big part to play in dictating which functions should be available and how they behave. (The book/chapter model is just an example I used to try and simplify the problem). Jeromy, I'm still really struggling to get this going, I don't suppose you've found time to knock up that demo app? Thanks in advance, Sorry guys, I haven't had a chance to get back to this yet. Dusty wrote: This doesn't seem right. How can you distinguish between something like /book/1/customMethod and /book/1/chapter? Dusty, you're right. I just had a quick look and I do have a custom action mapper that checks whether the pattern above references an action or method for that exact reason (it checks the list of available actions and gives precedence to those). Works great for me. I released another actionmapper that solved the problem using a different approach. It will be deprecated, but it's still up for info: http://code.google.com/p/struts2urlplugin/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST plugin URL syntax
The trick (I believe) is that the url should be parsed from right to
left, not left to right. I don't think it's a hijack; for the
application I'm working on context is very important so knowing that a
given resource is being accessed in the context of another resource
has a big part to play in dictating which functions should be
available and how they behave. (The book/chapter model is just an
example I used to try and simplify the problem).
Jeromy, I'm still really struggling to get this going, I don't suppose
you've found time to knock up that demo app?
Thanks in advance,
Mike
2008/7/6 dusty <[EMAIL PROTECTED]>:
>
> This doesn't seem right. How can you distinguish between something like
> /book/1/customMethod and /book/1/chapter? Is it smart enough to see that
> chapter is a mapped action and customMethod is not and change what it
> invokes? If it works then great, but doesn't it feel like a hijack?
>
> As I look at apps in Struts and Rails I realize that I really don't ever
> need to address a child resource with something like /books/1/chapters/1.
> That is because the :id property for chapter is unique and so you just
> address chapters with /chapters/1. Most of the time, once I get a child I
> can figure out who the parent is in the action rather than relying on the
> url to tell me. I suppose that if :id is not unique for chapter and is some
> kind of composite that requires the book id in order to look the chapter up
> then you need both pieces of information, but that is an exception case,
> right?
>
> Either way, I am definitely interested on how Jeremy got this to work using
> namespaces. Are you using Codebehind or Convention Jeremy?
>
>
> Jeromy Evans - Blue Sky Minds wrote:
>>
>> Mike Watson wrote:
>>> Hi Jeromy,
>>>
>>> I've finally found time to try to resolve this but haven't had much luck.
>>>
>>> Just to recap, I'm looking to be able to do something similar to the
>>> following:
>>> /book -> returns a list of books
>>> /book/123 -> returns book with id 123
>>> /book/123/chapter/1 -> return chapter with id 1, retrieved from book
>>> 123 (this is a simplistic example, all resources have a unique ID)
>>>
>>> I'd also like to be able to control access based on the
>>> context/namespace used to access a resource e.g.:
>>> /logo/abc -> read or update
>>> /book/123/logo/abc -> read only
>>> (would I need multiple LogoControllers for this?)
>>>
>>> Using Namespaces as described by Jeromy below certainly seems to make
>>> sense but as soon as I start to try the example provided I lose the
>>> ability to GET /book/123, and I've tried with BookController having
>>> namespace of "/" or "/book" and neither works. And so far I haven't
>>> been able to successfully hit the ChapterController using a url like
>>> /book/123/chapter.
>>>
>>> Am I missing something really obvious? Is there something I need to
>>> put in the struts.xml to configure the namespaces as well as using the
>>> @Namespace annotation?
>>>
>>> Jeromy, you seem to be pretty knowledgeable about this - can you think
>>> of anything I might be doing wrong?
>>>
>>> Thanks in advance for your help.
>>>
>>> Mike
>>>
>>>
>>
>> Hi Mike, I'll throw a quick answer together now and try to give you a
>> more in-depth one in a day or two by building an example.
>>
>> The steps are:
>> 1. ensure struts is up-to-date. (2.1.3-SNAPSHOT preferably, to ensure
>> you have the latest ActionMappingParamsInterceptor)
>> 2. enable the NamedVariablePatternMatcher via struts.xml
>> 3. Create the BookController in the root namespace. GET /book/123 will
>> invoke BookController.show() with id=123
>> 4. Create the ChapterController in the namespace containing the book id
>> variable (/book/{bookid}). GET /book/123/chapter will invoke
>> ChapterContoller.index() with bookId=123.
>>
>> ie.
>>
>> @Namespace("/")
>> public class BookController implements ModelDriven { }
>>
>>
>> @Namespace("/book/{bookId}")
>> public class ChapterController implements ModelDriven { }
>>
>>
>> Now that's what *should* happen. I use it in a large application that
>> includes many other related tweaks so I'll throw together a vanilla
>> sample and post it somewhere.
>>
>> I'll come back to the authorization issue separately. The quick answer
>> is that you can omit methods that are never permitted and/or filter URLs
>> based on a URI pattern and/or user's role.
>>
>> regards,
>> Jeromy Evans
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/REST-plugin-URL-syntax-tp17855192p18298747.html
> Sent from the Struts - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---
Re: REST plugin URL syntax
This doesn't seem right. How can you distinguish between something like
/book/1/customMethod and /book/1/chapter? Is it smart enough to see that
chapter is a mapped action and customMethod is not and change what it
invokes? If it works then great, but doesn't it feel like a hijack?
As I look at apps in Struts and Rails I realize that I really don't ever
need to address a child resource with something like /books/1/chapters/1.
That is because the :id property for chapter is unique and so you just
address chapters with /chapters/1. Most of the time, once I get a child I
can figure out who the parent is in the action rather than relying on the
url to tell me. I suppose that if :id is not unique for chapter and is some
kind of composite that requires the book id in order to look the chapter up
then you need both pieces of information, but that is an exception case,
right?
Either way, I am definitely interested on how Jeremy got this to work using
namespaces. Are you using Codebehind or Convention Jeremy?
Jeromy Evans - Blue Sky Minds wrote:
>
> Mike Watson wrote:
>> Hi Jeromy,
>>
>> I've finally found time to try to resolve this but haven't had much luck.
>>
>> Just to recap, I'm looking to be able to do something similar to the
>> following:
>> /book -> returns a list of books
>> /book/123 -> returns book with id 123
>> /book/123/chapter/1 -> return chapter with id 1, retrieved from book
>> 123 (this is a simplistic example, all resources have a unique ID)
>>
>> I'd also like to be able to control access based on the
>> context/namespace used to access a resource e.g.:
>> /logo/abc -> read or update
>> /book/123/logo/abc -> read only
>> (would I need multiple LogoControllers for this?)
>>
>> Using Namespaces as described by Jeromy below certainly seems to make
>> sense but as soon as I start to try the example provided I lose the
>> ability to GET /book/123, and I've tried with BookController having
>> namespace of "/" or "/book" and neither works. And so far I haven't
>> been able to successfully hit the ChapterController using a url like
>> /book/123/chapter.
>>
>> Am I missing something really obvious? Is there something I need to
>> put in the struts.xml to configure the namespaces as well as using the
>> @Namespace annotation?
>>
>> Jeromy, you seem to be pretty knowledgeable about this - can you think
>> of anything I might be doing wrong?
>>
>> Thanks in advance for your help.
>>
>> Mike
>>
>>
>
> Hi Mike, I'll throw a quick answer together now and try to give you a
> more in-depth one in a day or two by building an example.
>
> The steps are:
> 1. ensure struts is up-to-date. (2.1.3-SNAPSHOT preferably, to ensure
> you have the latest ActionMappingParamsInterceptor)
> 2. enable the NamedVariablePatternMatcher via struts.xml
> 3. Create the BookController in the root namespace. GET /book/123 will
> invoke BookController.show() with id=123
> 4. Create the ChapterController in the namespace containing the book id
> variable (/book/{bookid}). GET /book/123/chapter will invoke
> ChapterContoller.index() with bookId=123.
>
> ie.
>
> @Namespace("/")
> public class BookController implements ModelDriven { }
>
>
> @Namespace("/book/{bookId}")
> public class ChapterController implements ModelDriven { }
>
>
> Now that's what *should* happen. I use it in a large application that
> includes many other related tweaks so I'll throw together a vanilla
> sample and post it somewhere.
>
> I'll come back to the authorization issue separately. The quick answer
> is that you can omit methods that are never permitted and/or filter URLs
> based on a URI pattern and/or user's role.
>
> regards,
> Jeromy Evans
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/REST-plugin-URL-syntax-tp17855192p18298747.html
Sent from the Struts - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST plugin URL syntax
Thanks heaps Jeromy, I'll grab the 2.1.3 snapshot and try again.
A vanilla sample app would be great (others would probably find it useful too).
Cheers
Mike
2008/7/3 Jeromy Evans <[EMAIL PROTECTED]>:
> Mike Watson wrote:
>>
>> Hi Jeromy,
>>
>> I've finally found time to try to resolve this but haven't had much luck.
>>
>> Just to recap, I'm looking to be able to do something similar to the
>> following:
>> /book -> returns a list of books
>> /book/123 -> returns book with id 123
>> /book/123/chapter/1 -> return chapter with id 1, retrieved from book
>> 123 (this is a simplistic example, all resources have a unique ID)
>>
>> I'd also like to be able to control access based on the
>> context/namespace used to access a resource e.g.:
>> /logo/abc -> read or update
>> /book/123/logo/abc -> read only
>> (would I need multiple LogoControllers for this?)
>>
>> Using Namespaces as described by Jeromy below certainly seems to make
>> sense but as soon as I start to try the example provided I lose the
>> ability to GET /book/123, and I've tried with BookController having
>> namespace of "/" or "/book" and neither works. And so far I haven't
>> been able to successfully hit the ChapterController using a url like
>> /book/123/chapter.
>>
>> Am I missing something really obvious? Is there something I need to
>> put in the struts.xml to configure the namespaces as well as using the
>> @Namespace annotation?
>>
>> Jeromy, you seem to be pretty knowledgeable about this - can you think
>> of anything I might be doing wrong?
>>
>> Thanks in advance for your help.
>>
>> Mike
>>
>>
>
> Hi Mike, I'll throw a quick answer together now and try to give you a more
> in-depth one in a day or two by building an example.
> The steps are:
> 1. ensure struts is up-to-date. (2.1.3-SNAPSHOT preferably, to ensure you
> have the latest ActionMappingParamsInterceptor)
> 2. enable the NamedVariablePatternMatcher via struts.xml 3. Create the
> BookController in the root namespace. GET /book/123 will invoke
> BookController.show() with id=123
> 4. Create the ChapterController in the namespace containing the book id
> variable (/book/{bookid}). GET /book/123/chapter will invoke
> ChapterContoller.index() with bookId=123.
>
> ie.
>
> @Namespace("/")
> public class BookController implements ModelDriven { }
>
>
> @Namespace("/book/{bookId}")
> public class ChapterController implements ModelDriven { }
>
>
> Now that's what *should* happen. I use it in a large application that
> includes many other related tweaks so I'll throw together a vanilla sample
> and post it somewhere.
>
> I'll come back to the authorization issue separately. The quick answer is
> that you can omit methods that are never permitted and/or filter URLs based
> on a URI pattern and/or user's role.
> regards,
> Jeromy Evans
>
>
> -
> 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]
Re: REST plugin URL syntax
Mike Watson wrote:
Hi Jeromy,
I've finally found time to try to resolve this but haven't had much luck.
Just to recap, I'm looking to be able to do something similar to the following:
/book -> returns a list of books
/book/123 -> returns book with id 123
/book/123/chapter/1 -> return chapter with id 1, retrieved from book
123 (this is a simplistic example, all resources have a unique ID)
I'd also like to be able to control access based on the
context/namespace used to access a resource e.g.:
/logo/abc -> read or update
/book/123/logo/abc -> read only
(would I need multiple LogoControllers for this?)
Using Namespaces as described by Jeromy below certainly seems to make
sense but as soon as I start to try the example provided I lose the
ability to GET /book/123, and I've tried with BookController having
namespace of "/" or "/book" and neither works. And so far I haven't
been able to successfully hit the ChapterController using a url like
/book/123/chapter.
Am I missing something really obvious? Is there something I need to
put in the struts.xml to configure the namespaces as well as using the
@Namespace annotation?
Jeromy, you seem to be pretty knowledgeable about this - can you think
of anything I might be doing wrong?
Thanks in advance for your help.
Mike
Hi Mike, I'll throw a quick answer together now and try to give you a
more in-depth one in a day or two by building an example.
The steps are:
1. ensure struts is up-to-date. (2.1.3-SNAPSHOT preferably, to ensure
you have the latest ActionMappingParamsInterceptor)
2. enable the NamedVariablePatternMatcher via struts.xml
3. Create the BookController in the root namespace. GET /book/123 will
invoke BookController.show() with id=123
4. Create the ChapterController in the namespace containing the book id
variable (/book/{bookid}). GET /book/123/chapter will invoke
ChapterContoller.index() with bookId=123.
ie.
@Namespace("/")
public class BookController implements ModelDriven { }
@Namespace("/book/{bookId}")
public class ChapterController implements ModelDriven { }
Now that's what *should* happen. I use it in a large application that
includes many other related tweaks so I'll throw together a vanilla
sample and post it somewhere.
I'll come back to the authorization issue separately. The quick answer
is that you can omit methods that are never permitted and/or filter URLs
based on a URI pattern and/or user's role.
regards,
Jeromy Evans
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST plugin URL syntax
Hi Jeromy,
I've finally found time to try to resolve this but haven't had much luck.
Just to recap, I'm looking to be able to do something similar to the following:
/book -> returns a list of books
/book/123 -> returns book with id 123
/book/123/chapter/1 -> return chapter with id 1, retrieved from book
123 (this is a simplistic example, all resources have a unique ID)
I'd also like to be able to control access based on the
context/namespace used to access a resource e.g.:
/logo/abc -> read or update
/book/123/logo/abc -> read only
(would I need multiple LogoControllers for this?)
Using Namespaces as described by Jeromy below certainly seems to make
sense but as soon as I start to try the example provided I lose the
ability to GET /book/123, and I've tried with BookController having
namespace of "/" or "/book" and neither works. And so far I haven't
been able to successfully hit the ChapterController using a url like
/book/123/chapter.
Am I missing something really obvious? Is there something I need to
put in the struts.xml to configure the namespaces as well as using the
@Namespace annotation?
Jeromy, you seem to be pretty knowledgeable about this - can you think
of anything I might be doing wrong?
Thanks in advance for your help.
Mike
2008/6/18 Jeromy Evans <[EMAIL PROTECTED]>:
> Don Brown wrote:
>>
>> I believe it is technically possible to do this, but not at all
>> intuitive right now. This is probably my number one improvement
>> request for the REST plugin.
>>
>> You should be able change the wildcard mapper to one that recognizes
>> named wildcards then use them in your namespace annotation like this:
>> @Namespace("/book/{bookId}")
>>
>>
>> Don
>>
>
> Yeah, I use this feature heavily to support URIs matching Mike's
> requirement.
>
> in struts.xml
> name="namedVariablePatternMatcher"
> class="com.opensymphony.xwork2.util.NamedVariablePatternMatcher"/>
>
> in *actions.*.ChapterContoller.java
> @Namespace("/book/{bookId}")
> public class ChapterController implements ModelDriven {
>
> private void setBookId(Long id) {...}
> private void setId(Long id) { ..}
> private Chapter getModel() {...}
>
> public HttpHeaders show() {
> model = bookService.lookupChapter(bookid, id);
> if (model != null) {
> return new DefaultHttpHeaders("show");
> } else {
> return new DefaultHttpHeaders("error");
> }
> }
> public HttpHeaders index() {...}
> }
>
> and
>
> in *actions.BookContoller.java
> @Namespace("/")
> public class BookController implements ModelDriven { }
>
> regards,
> Jeromy Evans
>
>
>
> -
> 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]
Re: REST plugin URL syntax
Don Brown wrote:
I believe it is technically possible to do this, but not at all
intuitive right now. This is probably my number one improvement
request for the REST plugin.
You should be able change the wildcard mapper to one that recognizes
named wildcards then use them in your namespace annotation like this:
@Namespace("/book/{bookId}")
Don
Yeah, I use this feature heavily to support URIs matching Mike's
requirement.
in struts.xml
name="namedVariablePatternMatcher"
class="com.opensymphony.xwork2.util.NamedVariablePatternMatcher"/>
in *actions.*.ChapterContoller.java
@Namespace("/book/{bookId}")
public class ChapterController implements ModelDriven {
private void setBookId(Long id) {...}
private void setId(Long id) { ..}
private Chapter getModel() {...}
public HttpHeaders show() {
model = bookService.lookupChapter(bookid, id);
if (model != null) {
return new DefaultHttpHeaders("show");
} else {
return new DefaultHttpHeaders("error");
}
}
public HttpHeaders index() {...}
}
and
in *actions.BookContoller.java
@Namespace("/")
public class BookController implements ModelDriven { }
regards,
Jeromy Evans
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST plugin URL syntax
Folks, this type of nested resource is how a Rails REST url work and its
awesome. So easy to configure and so easy to use with things like
link_to :chapter_path(@book)
That will make the /book/book.getId()/chapter/chapter.getId() url. There
is no doubt that providing nested resources would make the REST
implementation in Struts2 better.
You are looking at the url from right to left. The first resource has a
parameter of id, and then for each level up the tree you get object_id for
the parameter.
So if I post a get for /book/1/section/2/chapter/12 I would get the
following parameters sent to the ChapterContoller: (id = 12, section_id = 2,
book_id = 1).
In apps with a REST design I only really need to know the parent in the url
when I am creating a child. So to use the book example,
(/chapters/new?parent_id=1). Once my chapter is created it is forever
connected to the book with id 1. After I create a chapter I can reference
it directly by its id (/chapter/22) and if I want the book I can do a
chapter.getBook() once I look up the chapter in the controller. I don't
really have many situations where something doesn't have a unique id and has
to be looked up with a combo of parent_id and child
number?position?whatever?
I don't think its useful to argue about what a "true" RESTful URL looks
like.
Mike Watson-2 wrote:
>
> Hmmm, I haven't come across the Namspace annotation stuff. I'll
> investigate that and see how I get on. If anyone can point me at some
> useful examples of how I might achieve this it'd be greatly
> appreciated.
>
> Thanks again for all the responses...
>
> 2008/6/17 Don Brown <[EMAIL PROTECTED]>:
>> I believe it is technically possible to do this, but not at all
>> intuitive right now. This is probably my number one improvement
>> request for the REST plugin.
>>
>> You should be able change the wildcard mapper to one that recognizes
>> named wildcards then use them in your namespace annotation like this:
>> @Namespace("/book/{bookId}")
>>
>> As I said, it really needs work as this is a huge deficiency in the
>> REST plugin right now, but the reason I haven't just made this easier
>> as I'm toying with the idea of borrowing the URI mapping behavior from
>> Jersey, which I find very intuitive, if a bit un-Struts/xwork-like.
>>
>> Don
>>
>> On Tue, Jun 17, 2008 at 9:10 AM, Mike Watson <[EMAIL PROTECTED]>
>> wrote:
>>> Well that'd be nice but I'm really struggling to get it to behave the
>>> way I want. Any thoughts on how I might do this?
>>>
>>> 2008/6/17 Dave Newton <[EMAIL PROTECTED]>:
--- On Mon, 6/16/08, Mike Watson <[EMAIL PROTECTED]> wrote:
> Can anybody suggest where I would start in an attempt to
> implement this hierarchical model?
The existing REST plugin?
Just an idea.
Dave
-
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]
>
>
>
--
View this message in context:
http://www.nabble.com/REST-plugin-URL-syntax-tp17855192p17959769.html
Sent from the Struts - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST plugin URL syntax
Hmmm, I haven't come across the Namspace annotation stuff. I'll
investigate that and see how I get on. If anyone can point me at some
useful examples of how I might achieve this it'd be greatly
appreciated.
Thanks again for all the responses...
2008/6/17 Don Brown <[EMAIL PROTECTED]>:
> I believe it is technically possible to do this, but not at all
> intuitive right now. This is probably my number one improvement
> request for the REST plugin.
>
> You should be able change the wildcard mapper to one that recognizes
> named wildcards then use them in your namespace annotation like this:
> @Namespace("/book/{bookId}")
>
> As I said, it really needs work as this is a huge deficiency in the
> REST plugin right now, but the reason I haven't just made this easier
> as I'm toying with the idea of borrowing the URI mapping behavior from
> Jersey, which I find very intuitive, if a bit un-Struts/xwork-like.
>
> Don
>
> On Tue, Jun 17, 2008 at 9:10 AM, Mike Watson <[EMAIL PROTECTED]> wrote:
>> Well that'd be nice but I'm really struggling to get it to behave the
>> way I want. Any thoughts on how I might do this?
>>
>> 2008/6/17 Dave Newton <[EMAIL PROTECTED]>:
>>> --- On Mon, 6/16/08, Mike Watson <[EMAIL PROTECTED]> wrote:
Can anybody suggest where I would start in an attempt to
implement this hierarchical model?
>>>
>>> The existing REST plugin?
>>>
>>> Just an idea.
>>>
>>> Dave
>>>
>>>
>>> -
>>> 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]
Re: REST plugin URL syntax
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.mydo
Re: REST plugin URL syntax
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] -
Re: REST plugin URL syntax
I believe it is technically possible to do this, but not at all
intuitive right now. This is probably my number one improvement
request for the REST plugin.
You should be able change the wildcard mapper to one that recognizes
named wildcards then use them in your namespace annotation like this:
@Namespace("/book/{bookId}")
As I said, it really needs work as this is a huge deficiency in the
REST plugin right now, but the reason I haven't just made this easier
as I'm toying with the idea of borrowing the URI mapping behavior from
Jersey, which I find very intuitive, if a bit un-Struts/xwork-like.
Don
On Tue, Jun 17, 2008 at 9:10 AM, Mike Watson <[EMAIL PROTECTED]> wrote:
> Well that'd be nice but I'm really struggling to get it to behave the
> way I want. Any thoughts on how I might do this?
>
> 2008/6/17 Dave Newton <[EMAIL PROTECTED]>:
>> --- On Mon, 6/16/08, Mike Watson <[EMAIL PROTECTED]> wrote:
>>> Can anybody suggest where I would start in an attempt to
>>> implement this hierarchical model?
>>
>> The existing REST plugin?
>>
>> Just an idea.
>>
>> Dave
>>
>>
>> -
>> 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]
Re: REST plugin URL syntax
Well that'd be nice but I'm really struggling to get it to behave the way I want. Any thoughts on how I might do this? 2008/6/17 Dave Newton <[EMAIL PROTECTED]>: > --- On Mon, 6/16/08, Mike Watson <[EMAIL PROTECTED]> wrote: >> Can anybody suggest where I would start in an attempt to >> implement this hierarchical model? > > The existing REST plugin? > > Just an idea. > > Dave > > > - > 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]
Re: REST plugin URL syntax
--- On Mon, 6/16/08, Mike Watson <[EMAIL PROTECTED]> wrote: > Can anybody suggest where I would start in an attempt to > implement this hierarchical model? The existing REST plugin? Just an idea. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST plugin URL syntax
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]
Re: REST plugin URL syntax
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]
Re: REST plugin URL syntax
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]
Re: REST plugin URL syntax
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]
