I'd vote for POST for exactly the reasoning <span></span>you describe. I'd also consider avoiding putting the trust ID in the URL for the same reason we don't want token ID's in URL's: it's a secret and effectively a credential.<div>
<div><br>On Thursday, December 20, 2012, Adam Young  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I originally wrote that the Trusts API was going to use the Authenticate  call (HTTP POST to   /tokens)  to get a token for the trust, but the more I think about it, the less I like this.  We have already overloaded that call with too many different ways to get a token.<br>

<br>
It would not  be proper instead to use:<br>
<br>
GET /trusts/{trustid}/token<br>
<br>
To get a token for a trust, GET is supposed to be idempotent.   It seems like it should be a POST verb, as we are getting back a new object.  Thus would<br>
<br>
POST /trusts/{trustid}/token<br>
<br>
Make more sense?  I can see an argument that getting a token should be under the token router and controller.  Thus maybe:<br>
<br>
POST /token/trusts/{trustid}<br>
<br>
Would be the right action and URL?  Any Feedback?<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a>OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div></div><br><br>-- <br><div><br></div>-Dolph<br>