鉴于我们提供了一个宁静的api，为书中实体提供服务
/books
客户可以按常规获得一本书
GET /books/{id}
假设我们想开始向我们最警惕的买家提供书籍折扣。这些买家将获得折扣代码，该代码将降低该书的价格。
因此，通用响应可能是
GET /books/4
{"id":4, "price":"24.95"}
对具有折扣代码的查询的回复可能是
GET /books/4
{"id":4, "price":"24.95", "yourPrice":"19.95"}
后端处理我们可以搞清楚，但客户提交折扣代码而不是一个宁静的api的最佳做法是什么？
某些书籍有资格享受折扣，而有些书籍则没有。折扣不会广泛（所有商品减免20％），而是会映射到特定代码（或客户/代码组合）的特定价格。
我们考虑过：
kludging url
GET / codes / {someCode} / books / {id}
在标题值中添加代码
使用查询字符串
GET / books？code = myCode
其他什么？
编辑：我们的目标不是实现一次性代码。相反，对于某些固定的帐套，这些折扣代码可以使用一定的固定次数。
答案 0 :(得分：2)
我喜欢使用查询变量。我刚看了 RESTful Web Services 这本书，这是我在这方面的主要参考，他们说：
仅使用查询变量进行建议 插入的参数 algorithm ...如果两个URI只有不同 在它们的查询变量中，它意味着 他们是不同的投入 进入相同的基础算法。
在我看来，您的折扣代码是折扣算法的输入。
查尔斯
答案 1 :(得分：1)
如果你要提交任何不是幂等的东西，我会建议使用POST而不是GET。您不希望客户端多次使用其代码。
答案 2 :(得分：1)
您在网址或标头值中添加的任何内容都会被截取，并可能允许其他用户“伪造”其折扣ID。 1方法是引入新的POST调用，允许使用简单的HTTPS加密ID。 POSTed数据可以像discountID或customerID一样简单。
添加 - 抱歉迈克尔，你已经说过了：）
答案 3 :(得分：0)
您可以在表格中注册代码，这样当用户检索到该图书时，会自动以适当的折扣返回该图书，例如：
用户可以添加一些代码
POST /register/{code}
这将在表{user} - {code}中添加一个条目，以便用户通过
进行检索GET /books/{id}
将使用该条目来应用折扣。我猜你在{code} - {book}之间已经有了一些关系，所以不会进入。