Open Stack

On 12/20/2012 11:10 PM, Dolph Mathews wrote:
> 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.
I suspected someone would respond with that.  It actually is not a 
secret.  The user must authenticate as themselves in order to get the 
token for the trust.  Anyone can know about the trust, only the trustee 
can get a token for that trust.

That said, it might be smart to hide the trust ID just because "why 
share it."

Would it make more sense to do as the payload
{trust_id:"123456789ABCDEF"}

And make the  POST to /token/trusts/{trustid}  ?



>
> 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
>
>
>
> -- 
>
> -Dolph
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121220/b0367200/attachment.html>