也许我混淆了事情或使它们过于复杂，但我正在努力开发支持HTML和JSON内容类型的RESTful API。例如，一个简单的用户管理功能。我希望有一个看起来像这样的API：
使用JSON有效负载发布到/ users的编程客户端将期望具有Location头的201 Created响应，该头指定新创建的用户的URL，例如， /用户/ 1。但是，通过其Web浏览器创建用户的人员将使用表单编码的有效负载发布到同一URL，并且可能会被重定向到用户列表页面，从而要求API返回302/303重定向，其Location位置为/用户。
从纯粹概念的角度来看，我发现API会根据提交的内容类型做出不同的反应，并且想知道这是不好的设计，这令人惊讶。然后，将程序化API和以网络为中心的API视为相同的API可能是错误的，并且不应该担心这些问题，并且更担心为不同的客户提供良好的体验。
您怎么看？
答案 0 :(得分：1)
你偶然发现了两个不同的问题。
一，典型的Web浏览器是一个非常糟糕的REST客户端。
两个，Web应用程序API不一定是REST API（参见＃1）。
因此，你试图为两位主人服务的难题。
当谈到工作流等细节时，表示与应用程序语义几乎没有关系，特别是如果你有相同的富媒体类型（相对于受约束的媒体类型，如图像，或其他）。
因此，就这些术语而言，鉴于类似的媒体类型，应用程序的行为方式确实不合适。
另一方面，媒体类型IS还是可以影响后端操作的请求的另一个方面。例如，你可以请求一个elided＆＃34; lite＆＃34;数据类型可能无法提供指向更丰富的媒体类型的api的其他部分的链接，或者您的授权级别是您可以查看哪些数据的因素，以及可用的其他关系，甚至是哪些媒体类型支持。
因此，请求有效负载的每个方面都会对特定语义和对服务器的任何特定请求的影响产生影响，这是公平的。在这种情况下，你的情景并没有真正脱离标记。
最后，它归结为文档，以阐明您作为API设计师的意图。