I'd vote for POST for exactly the reasoning 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.
On Thursday, December 20, 2012, Adam Young wrote:
> 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.
>
> It would not be proper instead to use:
>
> GET /trusts/{trustid}/token
>
> 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
>
> POST /trusts/{trustid}/token
>
> Make more sense? I can see an argument that getting a token should be
> under the token router and controller. Thus maybe:
>
> POST /token/trusts/{trustid}
>
> Would be the right action and URL? Any Feedback?
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
--
-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121220/1130d5ce/attachment.html>