如何根据 REST API 规范确定以下哪个统一资源标识符 (URI( 有效。
选择一个或多个选项
1. POST https://api.example.com/whales/create/9xf3df
2. PUT https://api.example.com/whales/9xf3df
3. GET https://api.example.com/whales/9xf3df?sort=name&valid=true
4. DELETE https://api.example.com/whales
REST 不关心你对资源标识符使用什么拼写约定;任何符合 RFC 3986 定义的生产规则的东西都可以。
/whales/create/9xf3df
/whales/9xf3df
/whales/9xf3df?sort=name&valid=true
/whales
/0cc846bb-678d-45d8-9c06-d9cf94cee0a5
/9xf3df/whales
这些都是很好的标识符。
"REST API"的标识符与网页的标识符完全相同 - 你可以使用任何你想要的拼写，浏览器，缓存，网络爬虫等将非常愉快地使用它们;这些通用组件将标识符视为标识符 - 它们不会试图从中提取任何含义。
作为演示，请注意以下所有工作方式完全符合您的期望：
- https://www.merriam-webster.com/dictionary/create
- https://www.merriam-webster.com/dictionary/get
- https://www.merriam-webster.com/dictionary/put
- https://www.merriam-webster.com/dictionary/post
- https://www.merriam-webster.com/dictionary/patch
- https://www.merriam-webster.com/dictionary/delete
REST 是否关心上述选项的发布、放置、获取和删除？
很难确定你在这里问的是哪个问题。
PUT /dictionary/delete HTTP/1.1
这是一个完全令人满意的请求行，并且对它的含义没有歧义。 在此示例中，PUT 是方法令牌;这告诉服务器我们正在请求将目标资源的表示形式(由/dictionary/delete标识(替换为请求消息正文中包含的表示形式
对于此特定资源，这可能意味着消息正文是一个 HTML 文档(我们会在标头中看到Content-Type: text/html，以确保服务器知道如何正确解释提供的字节(。
PATCH /dictionary/delete HTTP/1.1
这也是一个令人满意的请求行;我们再次请求更改/dictionary/delete资源的表示形式，但我们以略有不同的方式进行 - 我们不是在消息正文中包含替换表示形式，而是提供要进行的更改列表的表示形式(也称为"补丁文档"(。
统一的界面意味着我们应该期望www.merriam-webster.com的人们完全按照我们在这里描述的那样理解这些信息。
现在，对于这些特定资源，他们可能不希望随机堆栈溢出成员对其网站进行更改，因此他们可能会响应 403 禁止或 405 方法不允许。
所有通用组件都将理解这意味着什么，因为标准化响应元数据对所有资源都是通用的。