URI Token overridden by incoming arguments

[Jason Durham]

We have a resource configured to respond to /user/{userID}.  During testing, we mistakenly passed into this endpoint a parameter called "userID" and found that it overrode the token.  In looking at the source, this appears to be the desired behavior in buildRequestArguments.  So what is the best practice for token naming conventions?  

Jason Durham

[Adam Tuttle]

You're right that this was intentional! I've never heard of anyone building a convention to get around it, though.

If I had to, I'd probably prefix my token names with uri_ or token_ or something like that.

Adam

On Fri, Jan 30, 2015 at 2:41 PM, Jason Durham <jqdu...@gmail.com> wrote:

We have a resource configured to respond to /user/{userID}.  During testing, we mistakenly passed into this endpoint a parameter called "userID" and found that it overrode the token.  In looking at the source, this appears to be the desired behavior in buildRequestArguments.  So what is the best practice for token naming conventions?  

Jason Durham

--
You received this message because you are subscribed to the Google Groups "Taffy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taffy-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jason Durham]

Thanks for the quick reply.  We'll do as you suggested.

Jason

Jason Durham

--
You received this message because you are subscribed to a topic in the Google Groups "Taffy Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/taffy-users/tqaacqs3Qt8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to taffy-users...@googlegroups.com.