0

在开发 RESTFul Web 服务时，我对请求实体的建模感到困惑。处理请求所需的所有数据是否应该是实体的一部分，或者我应该将一些数据移动到 URL 路径中（假设我在这些数据中有逻辑层次结构）。

例如：

小路

/api/payment/3pResponse

实体架构 

{
  "marketplacedId" : String,
  "customerId: String,
  "contractId: String,
  "planId": String,
  "3pResonse" : {},
  "3pResponseURI" : "string" 
}

相对

小路

/api/payment/marketplaces/{mktId}/customers/{customerId}/contracts/{contractId}/plans/{plandId}/3pResponse

实体架构 

{
  "3pResonse" : {},
  "3pResponseURI" : "string" 
}

/api/payment/marketplaces/{mktId}请不要，我的应用程序中可能不存在路径上的资源。

两者中的任何一个在技术上都可以工作，但我想了解在这种情况下围绕实体建模的最佳实践。

4

1 回答 1

1

当您设计 REST API 时，您将功能需求映射到您的资源，类似于面向对象的设计方法。

资源是像对象一样的通用概念。资源有两个基本属性，它是可识别的，并且有一个或多个可从外部访问的表示。

在您的第一个示例 /api/payment/3pResponse中，您只有一个使用该方法完全更新的3PResponse资源。PUT

当您尝试访问它们时，您可以通过矩阵参数识别资源。（这只是您可以做到的一种方式，还有其他方式）

/api/payment/3pResponse;marketPlace=x;customerId=y;contractId=z;planId=k

在你的第二种方法中

/api/payment/marketplaces/{mktId}/customers/{customerId}/contracts/{contractId}/plans/{plandId}/3pResponse

3pResponse是市场、客户、合同和计划的子资源。

使用这种方法，人们可能会有这样的想法，即还有一个资源 /api/payment/marketplaces/可以返回市场列表，或者有一个资源/api/payment/marketplaces/{mktId}/customers/{customerId}/contracts/{contractId}可以返回客户的合同。

即使客户端不应尝试解释您的 uri，您的应用程序也应为这些资源返回有用的结果。

Stefan Tilkov有一个关于 REST API 设计REST 的精彩介绍：我不认为它意味着你认为它做了什么

比 URI 和资源的实际设计更重要的是保持 URI 稳定。

引用Tim Berners-Lee 的话：“酷 URI 不会改变”。

于 2016-07-13T04:01:40.053 回答