我应该使用哪个资源来保留我的API RESTFul？

我正在构建一个API以允许API的客户端发送通知来提醒用户更新订单状态。到目前为止，有两个通知：我应该使用哪个资源来保留我的API RESTFul？

当用户没有标记接收到的订单;
当用户没有标记为完成的顺序。

我想要构建这个API来简化扩展到与订单相关的其他通知，但为此API的客户端保留一个简单的URI。如何定义我的资源以保持我的API RESTFul？

我在想，我这些结构中的一个：

选项1：

POST: /api/ordernotification/receive/{id} 
POST: /api/ordernotification/complete/{id}

选项2（从资源忽略状态并发布它来代替）：

POST: /api/ordernotification/?id={id}&statusID={statusID}

编辑

方案2.1（保持关节URI，通过@Jazimov的建议）：

POST: /api/ordernotification/{statusID}/{id}.

哪种选择更合适？有一个选项比另一个有什么优势？或者有没有其他的选择我没有想到？

来源

2015-12-16 Bruno Pessanha

您可以使用：/ api/ordernotification/{statusID}/{id}。这是RESTful，因为你正在使用一个明确的URI，很明显你正在使用ordernotification函数 - 让路由从那里开始。如果您认为合适，您还可以灵活地添加状态。 – Jazimov

也许选项3：'PATCH/api/order/{id}'带'{status：“收到”}“。（[参考]（http://restcookbook.com/HTTP%20Methods/patch/）） – Kenney

@Kenney我认为PATCH将是有用的，如果我想更新订单的状态。在我的例子中，我只想发送一个通知告诉用户这样做。资源“订单”将保持不变。 –

我会的东西去沿着这些线路

POST /api/order/1234/notifications/not-received 
POST /api/order/1234/notifications/not-completed

可以在以后通过

GET /api/order/1234/notifications/not-received 
GET /api/order/1234/notifications/not-completed

或者

GET /api/order/1234/notification/8899

有一个关于如何语义丰富的一个URI没有真正限制访问可以，所以你不妨利用这一点，并明确表示。

来源

2015-12-16 15:26:34 guillaume31

我认为，要更新已插入记录的状态，您的端点应该是PUT而不是POST。

您可以使用

PUT: /api/ordernotification/:id/status/

与客户JSON数据

{ 
    "status": "your_status" 
}

根据请求数据，终端应更新记录。

来源

2015-12-16 14:04:58

我不想更新订单状态。此API将通知负责执行该操作的用户。所以在这种情况下，资源将是订单通知，而不是订单本身。 –

好的，那么我认为你的第二个选择更好。 –

如果我理解正确，您有两种类型的ordernotifications：通知receive的通知和通知complete的通知。如果这些是两个独立的数据模型，那么我认为将它们嵌套是一个好主意（即一个名为ReceiveOrderNotification和CompleteOrderNotification的表）。如果是这种情况，那么您可能希望完全暴露两个不同的端点，如POST /api/receiveordernotification和POST /api/completeordernotification。

但我不认为这是你能做的最好的事情，因为那里有很多重叠的相似之处，可能在订单通知之间。现在，选择2更像是一个GET，由于您使用的查询参数，那么你的第一个选项，让我们崩溃他们变成这样：

POST: /api/ordernotification/

，然后通过它的一些JSON数据来创建通知

{ 
    "orderId": "orderId", 
    "userId": "userId", 
    "prompt": "not marked received/not marked done" 
}

我也删除了/{id}，因为当你创建一个全新的东西时，通常你还没有创建id。即使客户端正在创建一个id并将其发送到API，将它保持打开状态也是一种很好的做法，因此您的API可以以自己的方式处理创建新的独特资源。

这是RESTful是因为POST创建了具有某些数据点的资源ordernotification。你的第一个选项本身就是一个资源，但在后台的任何数据模型中可能都没有。为了尽可能保持RESTful，您的API端点应该代表数据库域（表，集合等）。然后，让您的控制器根据请求中发送的数据选择使用哪些服务方法。否则，REST端点将提前公开所有逻辑，并成为一大串不可维护的端点。

来源

2015-12-16 14:29:29

我在指定请求中的状态时看到的唯一问题是，API的客户端需要知道要发送的状态，所以当他们可能只想发送1的通知时，我必须公开我的OrderStatus API状态，说完成。恕我直言，POST/api/completeordernotification会更简单和更有意义。 –

我应该使用哪个资源来保留我的API RESTFul？

回答

相关问题