如何创建不带动词的REST URL？

Question

我正在努力确定如何设计静态URL。我全力以赴地使用带有名词而不是动词的URL来解决这个问题。我们正在创建一项服务以实现财务计算器。计算器带有一系列参数，我们将通过CSV文件上传这些参数。用例将涉及：上载新参数获取最新参数获取给定营业日期的参数激活一组参数验证一组参数我收集的宁静方法是使用以下类型的URL：/parameters/parameters/12-23-2009您可以使用以下方法实现前三个用例：POST，您将参数文件包含在发布请求中GET第一个URL获取第二个URL但是，如何在没有动词的情况下使用第4和第5个用例呢？您不需要以下网址：/parameters/ID/activate/parameters/ID/validate??

Answer 1

也许像这样：

PUT /parameters/activation HTTP/1.1

Content-Type: application/json; encoding=UTF-8

Content-Length: 18

{ "active": true }

Answer 2

良好URI设计的一般原则：

• 不要使用查询参数来更改状态

• 如果可以，请不要使用大小写混合的路径；小写是最好的

• 不要在URI中使用特定于实现的扩展名（.php，.py，.pl等）

• 不要随便使用URI 进入RPC

• 不要限制你的URI的空间尽可能地

• 路径段要尽量短

• 做不是选/resource或/resource/; 从您不使用的位置创建301重定向

• 做一个资源的子选择使用查询参数; 即分页，搜索查询

• DO移动的东西出来的URI的，应该是在HTTP报头或身体

（注意：我没有说“ RESTful URI设计”； URI在REST中本质上是不透明的。）

HTTP方法选择的一般原则：

• 永远不要使用GET更改状态；这是让Googlebot破坏您一天的好方法

• 除非要更新整个资源，否则不要使用PUT

• 除非您也可以合法地对同一URI执行GET，否则请勿使用PUT

• 不要使用POST来检索寿命长或可能合理缓存的信息

• 不执行不操作幂等与PUT

• 不要使用GET为尽可能

• 做优先投入使用POST有疑问时

• 不要使用文章时，你要做的东西，感觉RPC样

• 不要使用PUT对资源类，较大或分层

• 请优先使用删除博文，删除资源

• 请勿将GET用于计算之类的事情，除非您的输入很大，在这种情况下，请使用POST

使用HTTP进行Web服务设计的一般原则：

• 不要将元数据放在应放在标题中的响应主体中

• 请勿将元数据放在单独的资源中，除非包含元数据会造成大量开销

• 请使用适当的状态码

• 201 Created创建资源后；发送响应时资源必须存在

• 202 Accepted 成功执行操作或异步创建资源后

• 400 Bad Request当某人对明显伪造的数据进行操作时；对于您的应用程序，这可能是验证错误；通常为未捕获的异常保留500

• 401 Unauthorized当有人在不提供必要Authorization标头的情况下访问您的API 时，或其中的凭据Authorization无效时；如果您不希望通过Authorization标头获得凭据，请不要使用此响应代码。

• 403 Forbidden 当有人以恶意方式或未经授权的方式访问您的API时

• 405 Method Not Allowed 当某人使用POST时应该使用PUT等

• 413 Request Entity Too Large 当某人试图向您发送不可接受的大文件时

• 418 I'm a teapot 尝试用茶壶冲泡咖啡时

• 不要使用缓存头时，您可以

• ETag 当您可以轻松地将资源减少为哈希值时，标头就很好

• Last-Modified 应该向您表明，保持资源更新的时间戳记是一个好主意

• Cache-Control并且Expires应该被赋予明智的价值

• 做一切你能兑现在请求缓存头（If-None-Modified，If-Modified-Since）

• 请在合理的情况下使用重定向，但是对于Web服务来说，重定向应该很少

关于您的特定问题，POST应该用于＃4和＃5。这些操作属于上面的“类似于RPC”的准则。对于＃5，请记住POST不一定必须使用Content-Type: application/x-www-form-urlencoded。这很容易就是JSON或CSV负载。

Answer 3

每当您需要新的动词时，请考虑将其转换为名词。例如，将“激活”转换为“激活”，将“验证”转换为“验证”。

但是仅从您编写的内容来看，我会说您的应用程序存在更大的问题。

每当提出一种称为“参数”的资源时，它都应该在每个项目团队成员的脑海中发出危险信号。“参数”实际上可以应用于任何资源；还不够具体。

“参数”到底代表什么？可能有很多不同的事物，每个事物都应该有一个专用于它的资源。

另一种解决方法-与最终用户（可能对编程了解甚少的最终用户）讨论应用程序时，他们自己反复使用哪些词？

这些是您应该在周围设计应用程序的词。

如果您尚未与潜在用户进行这种转换，请立即停止一切操作，除非您这样做，否则不要再编写其他代码！只有这样，您的团队才能了解需要构建什么。

我对金融软件一无所知，但是如果我不得不猜测，我会说某些资源可能会使用“ Report”，“ Payment”，“ Transfer”和“ Currency”之类的名称。

关于软件设计过程的这一部分，有很多不错的书。我可以推荐的两个是域驱动设计和分析模式。