Java JAX-RS中的不同HTTP方法返回什么？

我正在练习使用RESTEasy实现构建RESTFUL API。但是，对于根据HTTP方法应该返回什么，我仍然有点困惑。这就是我目前的做法：

@GET

返回一个实体

@POST

返回带有实际创建实体的HTTP响应

@PUT

返回更新了实际实体的HTTP响应

@DELETE

返回删除实际实体的HTTP响应

这是我的控制器的一个示例，用于说明

@GET
@Path("/{bookId}")
@Produces(MediaType.APPLICATION_JSON_VALUE)
public Book getBookById(@PathParam("bookId") Integer bookId) {
    return bookService.getBookById(bookId);
}

@POST
@Consumes(MediaType.APPLICATION_JSON_VALUE)
@Produces(MediaType.APPLICATION_JSON_VALUE)
public Response inertBook(@Valid Book book) {
    return bookService.insertBook(book);
}

@DELETE
@Path("/{bookId}")
public Response deleteBook(@PathParam("bookId") Integer bookId) {
    return bookService.deleteBook(bookId);
}

@PUT
@Path("/{bookId}")
@Consumes(MediaType.APPLICATION_JSON_VALUE)
@Produces(MediaType.APPLICATION_JSON_VALUE)
public Response updateBook(@PathParam("bookId") Integer bookId, @Valid Book book) {
    return bookService.updateBook(bookId, book);
}

阅读，他们实施

RESTEasy是JAX-RS（今天是雅加达EE的子规范）的实现。为了理解响应是如何生成的（这是您在考虑资源方法可以返回什么时需要知道的），您应该理解响应是如何工作的

资源方法几乎可以返回任何内容，包括

字符串

、

响应

、一些自定义bean等，但这与方法返回的内容无关，而是

MessageBodyWriter

实现如何将输出流转换为HTTP响应体

实体提供者（即

MessageBodyWriter

实现）将从JAX-RS资源方法返回的值转换为HTTP响应主体，具体取决于您指示方法设置为MIME类型的内容（使用

@products

，在方法之上）JAX-RS将：

查找

@产生的
值
然后查找相应的转换器/
MessageBodyWriter
（如果在类路径上找不到所需的实现，将引发转换异常）
使用
@products（MediaType.TypeHere）
将输出流序列化为您指示它返回的任何内容，并将返回它
请记住，返回非void Java类型会导致200 OK响应，而void方法会导致204 No Content响应

@products
通过向响应添加
内容类型
头，指定资源方法应生成的响应正文的MIME类型。对于不同的MIME类型，您需要一个相应的转换器库（MessageBodyWriter的实现）来返回您所指示的媒体/MIME类型

附带说明：JAX-RS是RESTful web服务的规范，这意味着在大多数情况下，您最好使用JSON

-客户端正在尝试检索资源，或者换句话说，获取资源。因此，是的，您应该返回一个状态代码为“200OK”的实体。在大多数情况下，它要么是单个资源，要么是集合资源；在您的示例中，可以是一本书，也可以是所有的书


-创建新资源时，客户端通常会发送要创建的新书的表示。客户端没有的是资源的标识符或以后如何访问资源。通常所做的是将
位置
头发送回客户端，以便客户端以后可以访问资源。此响应的状态应为“201 Created”（201 Created）（可选），您可以发回客户端发送的相同表示，但包括新创建的标识符。您可以在中看到一个示例


-这是一个完整的更新。因此，无论客户端发送什么，都会完全覆盖当前资源（不包括标识符）。因此，最终，客户已经掌握了所有信息；不需要寄任何东西回来。您只需回复“204无内容”状态即可。在代码方面，您可以简单地使用void方法或返回
响应
来显式设置状态


-如果删除一切顺利，则无需发送任何内容，只需让客户知道一切正常。因此，简单地发送一个“200OK”响应是合适的。或者，包括已删除的表示也可以


这些是非常普遍的指导方针。每个人都有自己的风格，但大多数人都试图遵循标准。下面是一些您可以深入了解的资源






在一边
我正在查看您的服务层实现（BookService类）是如何实现的，并且存在一些设计缺陷。通常，在分层应用程序中，较低的层不应该知道它上面的层的任何信息。下面是一个分层的示例

  WEB
   ↓
SERVICE
   ↓
  DAO


WEB层是REST层（JAX-RS代码）
服务层是业务发生的BookService
DAO层是稍后进行数据访问的数据层

在这种体系结构中，DAO层不应该知道服务层，服务层不应该知道WEB层。但在您的示例中，您的服务知道
Response
对象。
响应
应仅在WEB层中使用。更好的实现可能类似于

public Response getBook(@PathParam("id") long id) {
    Book book = bookService.findBook(id);
    if (book == null) {
        throw new NotFoundException();
    }
    return book;
}
  

现在BookService只负责查找图书，resource方法处理所有web逻辑