是一个具有空正文的POST请求，是一个纯ID值的文本格式RESTful响应

在基于jax-rs框架的REST API项目中，有一个客户端点：

customer/

该端点有一个POST方法，输入体为空，状态为SUCCESS（201）的响应只是一个自动生成的纯文本格式的ID值，既不表示JSON，也不表示XML

问题1：在RESTful API中使用空输入体发出POST请求正常吗？

问题2：仅返回纯文本格式的值的实现仍然是有效的RESTful API吗？这是一个很好的实践吗？这种执行有什么问题？如何改进？就个人而言，我对这样的实施感到很奇怪，但我真的无法说出问题所在

如果我实现POST方法，我可能会返回JSON或xml格式的响应，而不是纯文本值，如：

---

{id:1234567}

是返回JSON对象更好。这样您就有了一致的API，只需要处理JSON响应。

让端点接受空的POST请求就可以了。如果这在你的上下文中有一个合理的含义，那是完全正确的。这听起来像是创建了一个新的编号资源，它不需要任何参数就可以被创建，所以用例是完美的。您可以使用更好的总体设计，也可以不使用更好的总体设计，而不是创建一个没有参数的新资源的设计，但是如果不知道更多的细节，没有人可以告诉您

至于返回纯文本内容，如果它对您的用例有意义的话，通常也是完全有效的。在您的API中保持一致性是一个好主意，但是没有内在的技术需求。例如，如果您的一些端点返回二进制数据（例如，一个PDF文件），那么为了一致性起见，将其包装为JSON或XML或其他格式是完全没有意义的。因此，API中的混合响应类型通常没有问题

话虽如此，如果您的一些端点返回JSON，其他端点返回XML，还有其他端点返回纯文本，这可能会让API的使用者感到困惑和恼火，因为他们需要预期各种不同的响应格式，这比只需要预期一种响应格式要复杂得多

在RESTful API中使用空输入体发出

POST

请求是否正常

在请求中，服务器根据资源自身的特定语义处理在请求负载中发送的表示。如果不需要表示，则可以接受空有效负载。引述：

POST

方法请求目标资源根据资源自身的特定语义处理请求中包含的表示

---

仅返回纯文本格式的值的实现仍然是有效的RESTful API吗？这是一个很好的实践吗？这种执行有什么问题？如何改进

如果由于此请求而创建了资源，则必须返回。如果新创建的资源驻留在与目标URI不同的URI中，则必须返回头

201

（已创建）状态代码表示请求已完成，并导致创建一个或多个新资源。由请求创建的主要资源由响应中的

位置

头字段标识，如果未收到

位置

字段，则由有效请求URI标识

---

如果愿意的话，可以在有效负载中返回一个资源标识符和头。

Yes返回一个JSON对象更好。这样，您就有了一致的API，只需要处理JSON响应。Content-Type标头指示响应的格式，真正的RESTful API和使用者应该可以说是内容类型无关的；毕竟，您可以用不同的等效格式序列化相同的数据。因此，尽管保持事情的一致性可能是个好主意，但无论如何都不是必须的。所以这只是一个观点。@deceze如此“一致”意味着如果端点中的一个请求返回纯文本作为输出，那么所有其他请求都应该返回纯文本，对吗？@Rui Yes。或者相反，如果任何其他端点返回JSON或XML，那么所有端点都应该返回JSON或XML。同样，这并没有技术上的原因，它只是让API的消费者更容易，因为他们可以有一致的期望。但这取决于你的具体情况。例如，如果一个端点将返回二进制数据（例如，PDF），那么为了一致性起见，向后弯曲并用JSON封装这些数据是没有意义的。