我正在努力确定如何设计宁静的 URL。我完全赞成使用带有名词而不是动词的 URL 的宁静方法，我不明白如何做到这一点。
我们正在创建一项服务来实现财务计算器。计算器采用一堆参数，我们将通过 CSV 文件上传这些参数。用例将涉及：
我收集安静的方法是使用以下类型的 URL：
/parameters
/parameters/12-23-2009
您可以通过以下方式实现前三个用例：
但是你如何在没有动词的情况下完成第 4 和第 5 用例呢？你不需要像这样的网址：
/parameters/ID/activate
/parameters/ID/validate
??
良好 URI 设计的一般原则：
/resource或/resource/; 从您不使用的重定向创建 301 重定向（注意：我没有说“RESTful URI 设计”；URI 在 REST 中本质上是不透明的。）
HTTP方法选择的一般原则：
使用 HTTP 设计 Web 服务的一般原则：
201 Created创建资源后；资源在发送响应时必须存在202 Accepted成功执行操作或异步创建资源后400 Bad Request当有人对明显虚假的数据进行操作时；对于您的应用程序，这可能是一个验证错误；通常为未捕获的异常保留 500401 Unauthorized当有人在没有提供必要的Authorization标头的情况下访问您的 API 或其中的凭据Authorization无效时；如果您不希望通过Authorization标头获得凭据，请不要使用此响应代码。403 Forbidden当有人以可能是恶意的方式或未经授权的方式访问您的 API 时405 Method Not Allowed当有人在他们应该使用 PUT 时使用 POST 等413 Request Entity Too Large当有人试图向您发送一个无法接受的大文件时418 I'm a teapot 尝试用茶壶冲泡咖啡时ETag当您可以轻松地将资源减少为哈希值时，标头很好Last-Modified应该向您表明，保留资源更新时间的时间戳是个好主意Cache-Control并且Expires应该被赋予合理的价值If-None-Modified, If-Modified-Since)关于您的具体问题，POST 应该用于#4 和#5。这些操作属于上述“类 RPC”指南。对于 #5，请记住 POST 不一定必须使用Content-Type: application/x-www-form-urlencoded. 这可以很容易地成为 JSON 或 CSV 有效负载。
也许是这样的：
PUT /parameters/activation HTTP/1.1
Content-Type: application/json; encoding=UTF-8
Content-Length: 18
{ "active": true }
每当您看起来需要一个新动词时，请考虑将那个动词变成名词。例如，将“激活”变为“激活”，将“验证”变为“验证”。
但就您所写的内容而言，我会说您的应用程序存在更大的问题。
每当提出一种称为“参数”的资源时，它都应该在每个项目团队成员的脑海中发出危险信号。“参数”可以从字面上适用于任何资源；它不够具体。
“参数”究竟代表什么？可能有很多不同的东西，每一个都应该有一个单独的资源专门用于它。
另一种解决方法 - 当您与最终用户（可能对编程知之甚少的人）讨论您的应用程序时，他们自己重复使用的词是什么？
这些是您应该围绕这些词来设计您的应用程序。
如果您尚未与潜在用户进行此转换 - 立即停止一切，在您完成之前不要编写另一行代码！只有这样，您的团队才会知道需要构建什么。
我对金融软件一无所知，但如果我不得不猜测的话，我会说一些资源可能会以“报告”、“付款”、“转账”和“货币”等名称命名。
URL 的设计与您的应用程序是否为 RESTful 无关。因此，短语“RESTful URLs”是无稽之谈。
我认为您应该更多地阅读 REST 实际上是什么。REST 将 URL 视为不透明的，因此不知道其中有什么，是否有动词或名词等等。您可能仍想设计您的 URL，但那是关于 UI，而不是 REST。
也就是说，让我们来回答您的问题：最后两种情况不是 RESTful 并且不适合任何类型的 RESTful 方案。这些就是你可能称之为 RPC 的东西。如果您对 REST 很认真，您将不得不重新考虑您的应用程序是如何从头开始工作的。要么放弃 REST，要么将您的应用程序作为 RPC 应用程序。
嗯，也许不是。
这里的想法是您必须将所有内容视为资源，因此一旦一组参数有一个您可以引用它的 URL，您只需添加：
GET [parametersurl]/validationresults
POST [paramatersurl]
body: {command:"activate"}
但同样，激活的东西是 RPC，而不是 REST。
激活和验证要求是您尝试更改资源状态的情况。将订单“完成”或其他请求“提交”没有什么不同。有很多方法可以对这些状态变化进行建模，但我发现一种通常有效的方法是为相同状态的资源创建集合资源，然后在集合之间移动资源以影响状态。
例如创建一些资源，例如，
/ActiveParameters
/ValidatedParameters
如果要使一组参数处于活动状态，则将该组添加到 ActiveParameters 集合中。您可以将参数集作为实体主体传递，也可以将 url 作为查询参数传递，如下所示：
POST /ActiveParameters?parameter=/Parameters/{Id}
使用 /ValidatedParameters 可以完成相同的操作。如果参数无效，则服务器可以向请求返回“错误请求”，以将参数添加到已验证参数的集合中。
我会建议以下 Meta 资源和方法。
激活参数和/或验证它们：
> PUT /parameters/<id>/meta HTTP/1.1
> Host: example.com
> Content-Type: application/json
> Connection: close
>
> {'active': true, 'require-valid': true}
>
< HTTP/1.1 200 OK
< Connection: close
<
检查参数是否有效：
> GET /parameters/<id>/meta HTTP/1.1
> Host: example.com
> Connection: close
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Connection: close
<
< {
< 'active': true,
< 'require-valid': true,
< 'valid': {'status': false, 'reason': '...'}
< }
<
看到 10 多年后没有答案真正说明如何在 REST 架构中设计 OP 中要求的这种东西，我感到有点难过，因此我觉得现在有必要这样做。
首先，什么是 REST？！首字母缩略词 REST 或 ReST 代表“Representational State Transfer”，并以某种表示格式定义资源状态的交换。表示格式趋向于协商的媒体类型。在表示格式的情况下，application/html可能是在浏览器中呈现的 HTML 格式的文本内容流，可能是在应用一些样式表格式以将某些元素定位在某些位置之后。
REST 原则上是我们都知道的可浏览 Web 的概括，尽管它针对各种应用程序而不仅仅是浏览器。因此，通过设计，适用于 Web 的相同概念也适用于 REST 架构。诸如如何以“RESTful”方式实现某事的问题围绕回答如何在 Web 页面上实现某事然后将相同的概念应用到应用程序层的问题来解决。
基于 Web 的计算器通常从一些“页面”开始，允许您在将输入的数据发送到服务器之前输入一些值进行计算。在 HTML 中，这通常是通过 HTML<form>元素来实现的，这些元素教客户端设置可用参数、发送请求的目标位置以及发送输入数据时应用的表示格式。这可以看起来像这样：
<html>
<head>
...
</head>
<body>
<form action="/../someResource" method="post" enctype="application/x-www-form-urlencoded">
<label for="firstNumber">First number:</label>
<input type="number" id="firstNumber" name="firstNumber"/>
<label for="secondNumber">Second number:</label>
<input type="number" id="secondNumber" name="secondNumber"/>
<input type="submit" value="Add numbers"/>
</form>
</body>
</html>
上面的示例 ie 声明有两个输入字段可以由用户或其他自动机填写，并且在调用提交输入元素时，浏览器负责将输入数据application/x-www-form-urlencoded格式化为发送的表示格式POST在这种情况下，通过指定的 HTTP 请求方法到提到的目标位置。如果我们进入1输入firstNumber字段并2进入secondNumber输入字段，浏览器将生成一个表示firstNumber=1&secondNumber=2并将其作为实际请求的正文有效负载发送到目标资源。
因此，向服务器发出的原始 HTTP 请求可能如下所示：
POST /../someResource
Host: www.acme.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 28
Accept: application/html
firstNumber=1&secondNumber=2
服务器可以执行计算并使用包含计算结果的另一个 HTML 页面进行响应，因为请求表明客户端理解这种格式。
正如 Breton 已经指出的那样，没有“RESTful” URL 或 URI 这样的东西。URI/URL 是它自己的东西，不应该向客户端/用户传达任何含义。在上面的计算器示例中，用户根本不感兴趣将数据发送到哪里，只对触发提交输入字段时发送请求感兴趣。服务器应该已经提供了执行任务所需的所有必需信息。
浏览器也可能不知道该请求实际上是在为计算器提供一些输入参数，它也可能是某种订单表单，它只返回下一个表单表示以继续订购过程或某种完全不同的类型资源。在这种情况下，它只是执行 HTML 规范要求的内容，它并不关心服务器实际在做什么。这个概念使浏览器能够使用相同的表示格式来执行各种操作，例如从您喜欢的在线商店订购一些东西、与您最好的朋友聊天、登录在线帐户等等。
某些元素的可供性，例如在通常呈现为按钮的提交输入字段案例中，定义了您应该使用它做什么。对于按钮或链接，它基本上会告诉您单击它。其他元素可能传达不同的启示。这种可供性也可以通过链接关系来表达，即带preload注释的链接基本上告诉客户端它已经可以在后台加载链接资源的内容，因为用户很可能接下来会抓取该内容。这样的链接关系当然应该标准化或遵循Web 链接定义的关系类型的扩展机制。
这些是在 Web 上使用的基本概念，也应该在 REST 架构中使用。根据“Uncle Bob”Robert C. Martin的说法，架构是关于意图的，REST 架构背后的意图是将客户端与服务器分离，以允许服务器在未来自由发展，而不必担心它们会破坏客户端。不幸的是，这需要大量的纪律，因为很容易引入耦合或添加快速修复解决方案来完成工作并继续前进。正如 Jim Webber 在 REST 架构中指出的那样，作为服务提供商，您应该尝试设计一个类似于 70 年代基于文本的计算机游戏的域应用程序协议，客户将一直执行该协议，直到他们到达流程的末尾。
不幸的是，许多所谓的“REST”API 在现实中所做的一切都是如此。您会看到在 API 特定的外部文档中指定的主要基于 JSON 的数据的交换，通常很难动态地动态集成。请求需要的格式也被硬编码到外部文档中，这导致大量实现解释 URI 以返回预定义的类型而不是使用一些预先协商好的通用表示格式。这可以防止服务器发生变化，因为客户端现在期望接收预定义 URI 的某种数据格式（注意不是表示格式！）。这种自定义数据格式交换进一步阻止了客户端与其他 API 交互，因为“数据格式”通常是针对特定 API 的。我们从过去的 RPC 技术中知道这个概念，例如 Corba、RMI 或 SOAP，我们谴责它们在某种程度上是邪恶的，尽管最近 Peppol 再次使用它，将 AS2 替换为 AS4 作为默认传输协议。
关于提出的实际问题，将数据作为 csv 文件发送与使用application/x-www-form-urlencoded表示或类似的东西没有什么不同。Jim Webber 明确指出，毕竟HTTP 只是一种传输协议，其应用领域是通过 Web 传输文档。客户端和服务器至少应该都支持RFC 7111text/csv中定义的。此 CSV 文件可以作为处理媒体类型的结果生成，该媒体类型定义了表单元素、将请求发送到的目标元素或属性以及执行配置上传的 HTTP 方法。
有几种媒体类型支持HTML、HAL Forms、halform、ion或Hydra等表单。不过，我目前不知道一种可以自动将输入数据text/csv直接编码为的媒体类型，因此可能需要在IANA 的媒体类型注册表中定义和注册。
我猜完整参数集的上传和下载应该不是问题。如前所述，目标 URI 不相关，因为客户端只会使用 URI 来检索要处理的新内容。按营业日期过滤也应该不难。然而，这里服务器应该为客户端提供客户端可以选择的所有可能性。近年来，GraphQL 和 RestQL 不断发展，它们引入了一种类似 SQL 的语言，可以针对某个端点来获得过滤的响应。然而，在真正的 REST 意义上，这违反了 REST 背后的理念，因为 a) GraphQL 即仅使用单个端点，这会以某种方式阻止缓存的最佳使用 b) 需要了解可用字段，这可能会导致引入客户端耦合到资源的基本数据模型。
激活或停用某些配置参数只需触发提供此功能的超媒体控件即可。在 HTML 表单中，这可能是一个简单的复选框或列表中的多行选择或类似的。根据表单和它定义的方法，它可能会通过 发送整个配置，PUT或者对所做的更改很聪明，并且只通过PATCH. 后者基本上需要计算对更新表示的更改表示，并为服务器提供所需的步骤以将当前表示转换为所需的表示。根据PATH 规范，这必须在事务中完成，以便应用所有步骤或不应用任何步骤。
HTTP 允许并鼓励服务器在应用更改之前预先验证收到的请求。对于PUT，规格说明：
源服务器应该验证 PUT 表示是否与服务器对目标资源的任何约束一致，这些约束不能或不会被 PUT 更改。当源服务器使用与 URI 相关的内部配置信息来设置 GET 响应中表示元数据的值时，这一点尤其重要。当 PUT 表示与目标资源不一致时，源服务器应该通过转换表示或更改资源配置使它们保持一致，或者以包含足够信息的适当错误消息进行响应，以解释表示不合适的原因。建议使用 409（冲突）或 415（不支持的媒体类型）状态代码，后者特定于对 Content-Type 值的约束。
例如，如果目标资源配置为始终具有“text/html”的 Content-Type 并且被 PUT 的表示具有“image/jpeg”的 Content-Type，则源服务器应该执行以下操作之一：
一种。重新配置目标资源以反映新的媒体类型；
湾。将 PUT 表示转换为与资源一致的格式，然后将其保存为新的资源状态；或者，
C。使用 415（不支持的媒体类型）响应拒绝请求，指示目标资源仅限于“text/html”，可能包括指向不同资源的链接，该链接将成为新表示的合适目标。
HTTP 没有准确定义 PUT 方法如何影响源服务器的状态，超出了用户代理请求的意图和源服务器响应的语义所能表达的范围。...
总结这篇文章，您应该使用现有的媒体类型，它允许您向客户端介绍所需或支持的输入参数、将请求发送到的目标位置、要使用的操作以及媒体类型请求必须格式化，或者定义您自己在 IANA 注册的请求。如果要将输入转换为后者可能是必要的text/csv然后将 CSV 表示上传到服务器。验证应在更改应用于资源之前进行。实际的 URI 不应该与客户端相关，只是用于确定将请求发送到哪里，因此可以由您（服务实现者）自由选择。通过遵循这些步骤，您几乎可以获得随时更改服务器端的自由，并且如果客户端支持使用的媒体类型，则客户端不会因此而中断。
编辑：确实，URI 会阻止GET请求保持幂等性。
然而，对于验证，使用 HTTP 状态代码来通知请求的有效性（创建新的或修改现有的“参数”）将适合 Restful 模型。
400 Bad Request如果提交的数据无效并且必须在重新提交之前更改请求（HTTP/1.1 状态代码），请使用状态代码报告。
不过，这依赖于在提交时进行验证，而不是像在您的用例中那样推迟它。其他答案对这种情况有合适的解决方案。
在 REST 环境中，每个 URL 都是唯一的资源。你的资源是什么？财务计算器确实没有任何明显的资源。您需要深入了解您正在调用的参数并提取资源。例如，贷款的摊销日历可能是一种资源。日历的 URL 可能包括开始日期、期限（以月或年为单位）、期间（复利时）、利率和初始本金。有了所有这些值，您就有了一个特定的付款日历：
http://example.com/amort_cal/2009-10-20/30yrsfixed/monthly/5.00/200000
现在，我不知道您在计算什么，但是您的参数列表概念听起来不像 RESTful。正如其他人所说，您的上述要求听起来更像是 XMLRPC。如果您尝试使用 REST，则需要名词。计算不是名词，它们是作用于名词的动词。你需要把它转过来把名词从你的计算中拉出来。