REST API架构的目标之一是客户端和服务器的解耦。
在规划REST API时,我遇到的一个问题是:“客户端如何知道POST方法的有效负载是什么?”。
API需要以某种方式向UI通信,给出特定资源的POST方法的有效负载。否则,我们又回到了依赖必须具备的超出带宽知识以使用API并再次紧密耦合的状态。
因此,我的想法是,在资源的GET操作的API响应中提供构建该资源的POST方法的有效负载的规范。这将包括字段名称、数据类型、最大长度等信息。 这个人有类似的想法。
处理这个问题的正确方法是什么?大多数人只是依赖超出带宽的信息吗?在现实世界中,人们是如何解决这个问题的? 编辑 我提出的解决此问题的方法在以下序列图中说明:
想法呢?
在规划REST API时,我遇到的一个问题是:“客户端如何知道POST方法的有效负载是什么?”。
API需要以某种方式向UI通信,给出特定资源的POST方法的有效负载。否则,我们又回到了依赖必须具备的超出带宽知识以使用API并再次紧密耦合的状态。
因此,我的想法是,在资源的GET操作的API响应中提供构建该资源的POST方法的有效负载的规范。这将包括字段名称、数据类型、最大长度等信息。 这个人有类似的想法。
处理这个问题的正确方法是什么?大多数人只是依赖超出带宽的信息吗?在现实世界中,人们是如何解决这个问题的? 编辑 我提出的解决此问题的方法在以下序列图中说明:
- 入口点
- 如何通过超媒体导航 API。
- 某人(用户)从客户端请求注册页面
- 客户端从 API 请求入口点,并接收所有超媒体链接以及有关如何合法遍历它们的元数据。
- 客户端根据与注册超媒体 POST 方法相关联的元数据构建注册表单。
- 用户填写表单并提交。
- 客户端使用正确的数据进行 POST 到 API,一切都很好。
想法呢?
GET /widget
。我会使用类似GET /widget/meta
这样的东西。但是,正如其他人所说,这将使您的UI与API对元数据的实现耦合在一起。但是,如果您遵循某些规范(或创建一个规范),则您只与规范耦合。 - Byron Sommardahl