票务系统会破坏我的 REST 范式吗？答案

【问题标题】：Does a ticketing system break my REST paradigm?票务系统会破坏我的 REST 范式吗？
【发布时间】：2011-10-19 03:35:01
【问题描述】：

所以在previous question 中，我询问了做身份验证之类的最 RESTful 方式。响应是创建一个票务系统，在该系统中发布一个帖子，并发出一张票。然后所有进一步的请求都将随这张票一起发送。我的问题是，如何以 RESTful 方式随每个请求一起发送此标记？ GET 看起来像：

http://www.mysite.com/resource?ticket=ticketnumber

既然我包含了参数，这不是开始变得 RPCish 了吗？

【问题讨论】：

更像http://www.mysite.com/tickets（门票列表）或http://www.mysite.com/tickets/123（门票123）
不，我的意思是资源请求必须包含票
一般来说简单是好事。但是纯 REST 假设世界比实际情况要简单得多。对于 95% 的问题，这无关紧要，因为 REST 已经足够好了。但对于另外 5% 来说，这简直太天真了。另一方面，Web 服务可以处理几乎所有有关授权、安全和状态的情况，但这样做的代价是复杂程度几乎是荒谬的。您遇到的情况可以通过 REST 加上几个参数轻松处理——只要去做，不用担心“纯度”。
@JamesAnderson 这正是我想听到的。为什么不把它放在答案中让我投票呢？
@Kurtis - 与其说是答案，不如说是意见 - 所以我认为它更适合作为评论。另外我这个月有足够的代表:-}

【解决方案1】：

为什么不使用标准的 HTTP 身份验证方法而不是自己发明呢？如果它们不充分或不合适，请将您的凭据或票务信息添加到自定义标头中，而不是用它污染 URI。

您的 URI 应该标识您的资源，不多也不少。将元信息或上下文信息添加到 URI 会污染它们并使您的系统更难以发展，因为您的身份验证机制将直接且永久地与您的资源耦合。相反，将您的身份验证机制移动到它所属的 HTTP 标头中。

【讨论】：