在REST中使用'createModel'是一种好习惯吗？

Question

我正在寻找实现REST-full应用程序端点的最佳方法，该端点将负责创建新的库订单。假设我有以下资源。

如果我想获取特定作者的所有书籍，可以使用下一个端点：

HTTP GET
api/books/author/123

如果我想获取特定书籍的所有订单，可以使用以下提供的端点：

HTTP GET
api/books/456/orders

我的问题是，最能创建订单的端点的URL和请求模型是什么？ 在我看来，可能是

HTTP POST
api/books/456/orders

还有一个问题。在REST中使用CreateOrder之类的请求模型是一种好习惯吗？如果要创建一个REST-full Web应用程序，可以使用以下请求模型：

class CreateOrder 
{
   AuthorId: number;
   BookId: number;
   ClientId: number;
} 

有时候这让我感到困惑。请求模型应该看起来像我们的资源吗？

Answer 1

  

让我们假设我有以下资源。

您的“资源”看起来像“表格”。资源更接近关于信息的（逻辑）文档。

  

什么是最合适的URL，以及将创建订单的端点的请求模型

在大多数情况下，创建订单所用的URL无关紧要。在超媒体应用程序（例如HTML）中，我将提交一个“表单”，与该表单关联的元数据将为客户端描述如何从表单数据组成请求。

因此，操纵表单的人员或代码不需要了解有关URL的任何信息（您上次查看Google实际将搜索发送到的位置是什么时候？）

就通用Web组件而言，URL / URI只是一个不透明的标识符-它们不在乎拼写表示的含义。

他们关心的事情是拼写是否与他们缓存的内容相同。成功发送POST /x消息的后果之一是/x的缓存表示无效。

因此，如果您愿意，您可以考虑在创建订单时应该刷新哪个缓存的文档，然后将请求发送到该文档的标识符。

  

请求模型应该看起来像我们的资源吗？

没有必要。再次考虑一下网络-如果要发布表单数据，创建订单的表示将是什么样？

clientId=1&bookId=2

或者也许

bookId=2&copies=3

如果使用授权标头回答“正在创建订单的人”。

在我们的HTTP请求和响应中，我们从根本上发送消息表示形式-符合某种模式的字节序列。并没有特殊的原因，这些字节序列必须或不能与实现中其他地方的字节序列相同。

Answer 2

您的端点不必始终以/books开头。您可以引入另一个端点/orders来创建或获取订单。因此，要创建订单，您可以：

HTTP POST
api/orders 

您所说的“请求模型”是HTTP请求主体结构吗？如果是，则不需要与您的后端持久性/域模型100％匹配。只需包含服务器创建订单所需的足够参数即可。 （例如，包括bookId而不是整个book对象等）。

顺便说一句，要获取特定作者的所有书籍，更常见的是使用查询参数，例如：

HTTP GET
api/books?authorId=123

Answer 3

您正在做的不是REST，而是基于HTTP的CRUD。 REST不在乎您的URI结构，并且资源与数据库表相距甚远。如果仅需要CRUD，则下载CRUD生成器库https://github.com/search?q=crud+generator&type=Repositories，该库将生成所有大写字母，您无需手动编写。