logo标签列表

RESTful服务的命名规范是什么？

javarest
3

对于RESTful服务，名词可以省略和丢弃吗？

可以替换为 /service/555/111 吗？

第一种选项是必需的还是有多种选择和争议？

据我所知，这完全取决于您。如果您发现路径中的名称使调用内容更易于查看，请将它们保留在那里。 - Tim Biegeleisen
7个回答
3

完全由您决定，我认为使用名词的好处在于它可以帮助您从URL中看出服务试图实现什么目标。

此外，考虑到在客户下面您可以拥有像下面这样的内容，从URL中您可以区分客户的报价和订单：

  • /service/customers/555/quote/111
  • /service/customers/555/order/111
2
在某种程度上，命名RESTful端点的“规则”应该遵循像“Clean Code”这样的命名规则。
意思是：名称应该有意义。它们应该说出它们的意思，并且意思应该与所说的一致。
从那里来：它可能取决于该服务的性质。如果您只能为客户提供服务 - 那么您可以省略客户部分 - 因为这不会添加（很多）有意义的信息。但是，如果您稍后想为其他类型的客户提供服务呢？
换句话说：我们无法告诉您什么适合您的应用程序 - 因为这取决于您环境的要求/目标。
值得注意的是：不仅要考虑今天的要求。退后一步，考虑那些最有可能发生的“未来增长路径”。然后确保您今天定义的API将与这些未来的扩展很好地配合使用。
2
REST的核心之一是URL应被视为不透明实体。客户端应该永远不会创建URL，只能使用服务器提供的URL。只有托管实体的服务器需要了解URL结构。
因此，在设计服务时，请使用最合适的URL方案。
关于您提到的选项：
  • 省略名词会使扩展服务变得困难，例如，如果您想添加产品、收据或其他实体。
  • 将订单放在顾客下面让我感到惊讶（但再次强调，这取决于您设计服务的方式）。 我期望看到类似于/service/customers/555和/service/orders/1234567的内容。
无论如何，从服务返回的RESTful客户文档都应包含链接到他或她的订单以及反向链接（以及所有其他相关关系）。
1
与其使用 /service/customers/555/orders/111，我可以 / 应该暴露: /service/555/111 吗？
问题比较广泛，但由于使用 REST 路径来定义嵌套信息，因此必须尽可能明确。如果将长路径提供到 URL 中对您来说是个问题，则作为替代方案，请在请求的正文中提供上下文信息。
我认为短路径 /service/555/111 缺乏一致性。
假设 /service/555/111 对应于调用客户 555 和订单 111 的服务。您知道这一点。但 API 的客户端不一定知道路径的含义。
此外，现在假设您希望为客户 555 调用相同的服务，但是针对年份 2018。现在该怎么办？像这样：/service/555/2018 将容易出错，因为您必须添加参数以传达最后一个路径值，并且 service/555/years/2018 会使您的 API 定义不一致。

清晰、简洁和一致性非常重要。

1
根据我的理解，名词的使用并非必要或符合任何标准，但是它的使用有助于使您的终端点更加具体和易于理解。因此，如果任何命名法使您的URL更易于人类阅读或理解，则我通常会选择创建该类型的URL并保持简单。这也有助于服务使用者通过名称部分了解任何服务的功能。
0
0
对于RESTful服务，名词可以省略和丢弃吗？
可以。REST不关心您为资源标识符使用什么拼写。
URL缩短器可以正常工作。
拼写选择受本地约定的影响，它们在这个意义上很像变量。
理想情况下，拼写与底层域和数据模型无关，因此您可以更改模型而不更改API。Jim Webber以这种方式表达了这个想法：
“Web不是您的域，而是文档管理系统。所有HTTP动词都适用于文档管理域。URI不映射到域对象-这违反了封装。工作（例如向域模型发出命令）是管理资源的副作用。换句话说，资源是防腐层的一部分。您应该期望在集成域中有比业务域中的业务对象更多的资源。”
资源将您的域模型适应到Web上。

话虽如此，如果您希望客户通过阅读文档来发现URI（而不是从明确定义的超媒体响应中读取它们），那么使用遵循简单概念模型的URI拼写将是一个好主意。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接