有关JAX-RS中方法类型的最佳实践是什么?
我对以下方法感兴趣:GET,POST,PUT和DELETE。
我可能的方法:
获取 - 始终返回回复。
@GET
@Path("/path/{something}")
public T getT() {
...
return t; // t - instance of T
}
发表
@POST
@Path("/path")
public T/void createOrUpdate() {
...
return t; // t - instance of T
}
问:最好是返回整个创建的资源,还是只返回" ACK响应" void 方法?那么用作GET的POST(当我们想避免URL长度限制时)?
PUT
@PUT
@Path("/path")
public T/void createOrUpdate() {
...
return t; // t - instance of T
}
问:对于已创建/已更新的资源或不同的响应<, 方法或响应是否更好? / strong>用于创建/更新或仅 ACK响应?
删除
@DELETE
@Path("/path/{something}")
public T/void deleteT() {
...
return t; // t - instance of T
}
问:最好是使用 void 方法或返回已删除资源或返回 ACK响应< / strong>?
是否可以永远拥有T
= javax.ws.rs.core.Response
(使用T时)?
我看到了:
答案 0 :(得分:12)
JAX-RS是使用Java开发RESTful Web服务的规范。 Java EE中包含一个参考实现,但由于它是一个规范,因此可以编写其他框架来实现规范,包括Jersey,Resteasy等。
JAX-RS本身没有为REST API的返回类型和响应代码制定任何指导原则。但是,您可能希望遵循REST标准中的一些准则(这些不是硬性规则和快速规则):
Method GET
Successful Response RETURN the resource with 200 OK
Failure Response RETURN appropriate response code
Method POST
Successful Response RETURN the link to the newly created resource in Location response header with 201 status code
Failure Response RETURN appropriate response code
Method PUT
Successful Response RETURN the updated resource representation with 200 OK or return nothing with 204 status code
Failure Response RETURN appropriate response code
Method DELETE
Successful Response RETURN nothing with 200 or 204 status code
Failure Response RETURN appropriate response code
在实践中,POST适用于创建资源。应在Location响应头中返回新创建的资源的URL。 PUT应该用于完全更新资源。请理解这些是设计RESTful API时的最佳实践。这样的HTTP规范不限制使用PUT / POST,但有一些限制来创建/更新资源。请查看Twitter REST API best practices,其中总结了RESTful API的最佳实践。
答案 1 :(得分:6)
这个答案不正确/最新。请改为检查@ROMANIA_engineer答案。
你永远不应该归还无效。最佳做法是始终返回javax.ws.rs.core.Response
。但请注意,即使您使用void
定义webresource,您的服务器也会返回HTTP响应。
在POST
和PUT
上,最好返回修改后的资源,包括其ID。一些前端框架和/或中间件将使用它来将资源与您的服务器同步(例如,请参阅Backbone Model)。
在DELETE
上,它取决于您尝试实现的操作..但通常一个ACK就足够了。
注意:无论如何,无论您返回什么,都不要忘记尊重您的安全政策!
响应@Atul:当您从客户端发送HTTP请求或从服务器发送HTTP响应时,某些数据可能会受到保护。作为实例:
答案 2 :(得分:0)
我试一试并说“没有最好的做法”。这是因为底层协议(HTTP)实际上在任何情况下都有返回值(例如200-OK,500-Internal Error ...),除非您的服务也应该遵循断开的连接。
由于您没有按照自己的规则实施HTTP协议,而是自己设计的服务,没有最佳做法,您必须以与日常业务相匹配的方式定义“您的协议”最好的。
例如,当涉及到删除操作时,调用者可能根本不对响应感兴趣,或者期望您像堆栈一样工作并在调用时返回“已删除/已删除”元素。您需要了解最适合您需求的内容。