RESTAPI的“生成cli骨架”这样的设计模式的名称是什么？

我开发了一个RESTAPI。我想通过API本身提供请求参数。 这个想法的起源是

您知道关于RESTAPI端点返回请求参数的方法的任何名称或示例吗

例如，添加特殊请求头以显示如下所示的框架

curl-X POST-H生成骨架：Truehttps://exmaple.com/users

---

→ {姓名：，年龄：}

我脑子里的基本问题是：你为什么需要它

在我看来，就REST而言，这听起来像是一种反模式。REST是针对机器而非人类的可浏览Web的泛化，尽管适用于Web的相同概念基本上也适用于遵循REST体系结构的应用程序

大量CRUD服务允许通过POST请求创建新资源。这里，有效负载的语义由服务器定义。客户机需要关于如何创建这样的有效负载的带外信息，或者服务器需要以某种方式向客户机传授这样的信息。在Web上，这是通过表单完成的。表单不仅定义了所需的数据输入，还定义了将有效负载发送到何处。在遵循REST体系结构风格的应用程序中也可以这样做。在这里，表单应该被描述为服务器和客户端都使用和理解的自己的媒体类型，类似于服务器和浏览器知道和理解的HTML。在REST体系结构中没有表示表单的专用媒体类型的情况下，可以简单地重用HTML的表单功能，即

从服务器检索数据还应避免解释特定类型的资源。这很容易把你骗进监狱。相反，应该使用内容类型协商，当客户端通知服务器其功能，服务器尝试使用客户端可以使用的表示进行响应时。对于上面提到的表单示例，客户机和服务器可以就类似于application/form+json表示的内容达成一致，其中服务器基本上返回与HTML表单类似的信息，只是json语法。但是，应注意自定义媒体类型。它们应尽可能通用，以适用于大量客户机，否则对此类媒体类型的支持将非常有限

与HATEOAS一起，它基本上增加了对URI的支持并避免了对URI的解析和解释，但只使用它们来调用目标端点上的下一个操作，这是REST体系结构对客户端和服务器施加的基本先决条件，以获得高度的解耦，服务器端的自由发展，无需担心破坏客户机，并使客户机对变化更具鲁棒性

在应用这些步骤时，资源变得非常自我描述。如果操作正确，就不需要外部文档或其他带外信息，也不需要基于客户端的存根/骨架类与API交互，因为终端URI和HTTP是客户端需要支持的必要接口

如果您需要支持自定义头，服务器需要在没有自定义头的情况下通知客户机将其导出。这类似于基本身份验证。客户端向服务器发送一个请求，服务器响应401个未经授权的响应，该响应包含一个标头，如WWW-Authenticate:Basic realm=fooBar，该标头通知客户端服务器希望使用提及的域进行基本身份验证。许多客户机实现都知道，username:password等格式需要用户和密码/密钥，还需要对其进行base64编码并附加到基本字符串中。这通常是在后面完成的，而不需要你方的投入。但是，对于自定义标头，这可能不太容易实现自动化。但您仍然可以发出适当的错误代码，如409冲突或422不可处理实体，以通知客户端所需但缺少的头。这样的自定义头最好用媒体类型来描述，因为它们既包括对交换的表示的语法描述，也包括对交换的表示的语义描述，包括可选头

如果您需要生成此类属性以生成客户端存根代码或配置，那么您很可能没有REST，而更像是一个专门为与API交互而设计的RPC系统，但在任何其他端点上都会失败。根据其内部结构，如果您更改URI结构或消息格式中的某些内容，则此类客户端代码可能会很容易中断。这也非常类似于SOAP/WSDL客户机存根代码生成，其中可以检索服务的WSDL XML表示，生成一些存根类，然后针对这些面实现。这里的问题通常是，如果在 客户端存根代码已生成，客户端需要重新生成存根类，并最终更新其客户端代码以与创建的接口交互。如果您获取更新信息的唯一渠道是您不经常访问的渠道，即维护人员主页，则这一点尤其麻烦。在大多数情况下，只有当服务已经更新时，您才能看到问题。这件事发生在几年前的几次，迫使我们对部署在各种客户机上的应用程序进行一些更新，这需要我们花费几天的时间来更新这些应用程序

---

<>我希望你能明白为什么我认为这是一种反模式，在某种程度上，服务器应该用它需要的所有东西来通知客户，以采取进一步的行动，或者为客户提供一种方法来提供丢失的信息并发送给服务器。

< P>你是否考虑过使用像JSON模式这样的东西？ 如果您确实希望请求使用某种JSON模板，那么它们不应该存在于由资源访问的同一uri上

相反，您应该在API中创建一个单独的部分，例如：

GET /templates/user <- to fetch a 'skeleton' as you call it

---

要发现这些模板，可以从现有API中的战术位置创建链接。这可能是指向相关模板的某个链接：标题。

>它们不应该位于同一个uri上，由我同意设计的资源访问。链接头看起来也很方便。