RejectedSoftware Forums

Sign up

Route generation when parameter named "id*"

Hi all,

Why, when using the REST interface generator, are my routes calculated differently depending on the parameter name?

Specifically, getField(int id) is routed as :id/field (and this is true for any in (id1, id2, ...), whereas getField(int whateverothername) is routed as field with required URL encoded parameter whateverothername. Why is there special behavior for ‘id’ , and where can I find this documented?

Thanks in advance -- looking forward to playing with vibe.d.

Re: Route generation when parameter named "id*"

On 3/13/18 12:28 PM, James Blachly wrote:

Hi all,

Why, when using the REST interface generator, are my routes calculated differently depending on the parameter name?

Specifically, getField(int id) is routed as :id/field (and this is true for any in (id1, id2, ...), whereas getField(int whateverothername) is routed as field with required URL encoded parameter whateverothername. Why is there special behavior for ‘id’ , and where can I find this documented?

Thanks in advance -- looking forward to playing with vibe.d.

The only place I can find it "documented" online is here:

http://vibed.org/api/vibe.web.rest/registerRestInterface

If you look in the example, it shows :id being used.

But I don't see why it should use "id1" or "id2" anywhere. It's hard to
follow the code to see where this is determined.

I remember reading it in Kai's book.

-Steve

Re: Route generation when parameter named "id*"

On Tue, 13 Mar 2018 13:10:58 -0400, Steven Schveighoffer wrote:

On 3/13/18 12:28 PM, James Blachly wrote:

Hi all,

Why, when using the REST interface generator, are my routes calculated differently depending on the parameter name?

Specifically, getField(int id) is routed as :id/field (and this is true for any in (id1, id2, ...), whereas getField(int whateverothername) is routed as field with required URL encoded parameter whateverothername. Why is there special behavior for ‘id’ , and where can I find this documented?

Thanks in advance -- looking forward to playing with vibe.d.

The only place I can find it "documented" online is here:

http://vibed.org/api/vibe.web.rest/registerRestInterface

If you look in the example, it shows :id being used.

I did see that, but my confusion stems from the fact that parameters not named id will be interpreted as URL-encoded parameters, whereas parameter named id is integrated in the route. I guess this is more of a comment than a question: this is counter-intuitive and undocumented(?). Surprises like this make me hesitant to proceed with the (any) framework overall.

But I don't see why it should use "id1" or "id2" anywhere. It's hard to
follow the code to see where this is determined.

I have to recant; and must not have compiled the version of code I thought I did, because I now cannot reproduce this behavior (i.e., pattern matching id* ; comment still stands for parameter simply named id)

I remember reading it in Kai's book.

-Steve

Going to buy the ebook now...

James

Re: Route generation when parameter named "id*"

On 3/13/18 1:25 PM, James Blachly wrote:

On Tue, 13 Mar 2018 13:10:58 -0400, Steven Schveighoffer wrote:

I remember reading it in Kai's book.

Going to buy the ebook now...

Definitely worth getting, but if I may quote from his book:

"If the first parameter of a method is named id, then this parameter is
mapped to the void putData(string id, string data); path using the
/:id/data path. This is really a legacy mechanism but you must be aware
of it in order to avoid surprises."

So it seems that this is not really intended as a current "feature", but
supported for legacy reasons. And there aren't any other surprises he
goes over (unless you count parameters with leading underscores, but
that is a useful feature and is in the docs), so I'm pretty sure this is
the only issue you may come across.

It really should be in the docs IMO, especially in the main Rest API
doc. I'll file an issue.

-Steve

Re: Route generation when parameter named "id*"

On 3/13/18 1:44 PM, Steven Schveighoffer wrote:

I'll file an issue.

https://github.com/vibe-d/vibe.d/issues/2118

-Steve