票务系统是否会破坏我的 REST 范式？
因此，在上一个问题中，我询问了执行身份验证等操作的最 RESTful 方式是什么。对此的回应是创建一个票务系统，在该系统中发布帖子并发出票证。然后所有进一步的请求都将随此票一起发送。我的问题是，如何以 RESTful 方式随每个请求发送此标记？ GET 看起来会像这样：
http://www.mysite.com/resource?ticket=ticketnumber
既然我包含了参数，这不是开始变得 RPCish 了吗？
So in a previous question I asked about whats the most RESTful way to do something like authentication. The response was to create a ticketing system where a post was done, and a ticket was issued. Then all further requests would send along this ticket. My question is, how do I send along this ticked with each request in a RESTful manner? Would GETs look something like:
http://www.mysite.com/resource?ticket=ticketnumber
And isn't this starting to get RPCish now that I'm including parameters?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为什么不使用标准的 HTTP 身份验证方法而不是发明自己的方法？如果它们不够或不合适，请将您的凭据或票务信息添加到自定义标头中，而不是用它来污染 URI。
您的 URI 应该标识您的资源，不多也不少。向 URI 添加元或上下文信息会污染它们，并使您的系统更难以发展，因为您的身份验证机制将直接且永久地耦合到您的资源。相反，请将您的身份验证机制移至它所属的 HTTP 标头中。
Why not use standard HTTP authentication methods instead of inventing your own? If they're not sufficient or appropriate, add your credentials or ticketing info to a custom header rather than polluting the URI with it.
Your URIs should identify your resources, no more, no less. Adding meta or contextual information to the URI pollutes them and will make your system more difficult to evolve, because your authentication mechanism will be directly and permanently coupled to your resources. Instead, move your authentication mechanism into an HTTP header, where it belongs.