REST 可以在 POST 之后返回内容吗？

我正在使用 RESTlet 并且我已经创建了一个资源。我通过覆盖 acceptRepresentation方法来处理 POST。

客户机应该给我发送一些数据，然后我将其存储到 DB，将响应设置为201(SUCCESS _ CREATION) ，我需要向客户机返回一些数据，但返回类型为 acceptRepresentation的是 void。

在我的例子中，我需要返回一些标识符，以便客户端可以访问该资源。

例如，如果我有一个带有 URL /resource的资源，并且客户机发送 POST 请求，我将在 DB 中添加一个新行，其地址应该是 /resource/{id}。我需要发送 {id}。

我做错什么了吗？REST 原则允许在 POST 之后返回某些内容吗？如果是，我怎么做，如果没有什么是处理这种情况的方法？

112132 次浏览
小开

Output it in whatever format is requested. That might be:

<success>
<id>5483</id>
</success>

Or:

{ "type": "success", "id": 5483 }

It depends on what you usually do. If they're not expecting the data, they should just ignore it, but any client that wants to handle it properly should be able to.

小开
最佳答案

REST just says that you should conform to the uniform interface. In other words, it says you should do what POST is supposed to do as per the HTTP spec. Here is the quote from that spec that is relevant,

If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30).

As you can see from this, you have two places where you can indicate to the client where the newly created resource resides. The Location header should have an URL that points to the new resource and you can return an entity with the details also.

I'm not sure what the difference between overriding acceptRepresentation() and overriding post() but this example shows how to return a response from a POST.

小开

Two different questions:

Does the REST application pattern support returning data in a POST?

I don't think REST explicitly disallows it, but the preferred treatment is spelled out in Darrel's answer.

Does the RESTlet framework allow returning data in a POST?

Yes, even though it returns void, in a class which extends Resource, you have full access to the Response object object via the getResponse() method. So you can call getResponse().setEntity() with whatever data you want.

小开

If you respond 201 Created with an entity body, rather than a Location redirect, then it's a good idea to include a Content-Location header pointing to the resource that is being represented in the response.

This will avoid potential confusion - in which a client could (justifiably) assume that the response entity actually represents a new state of the 'creator', and not the created resource.

> POST /collection
> ..new item..


< 201 Created
< Location: /collection/1354
< Content-Location: /collection/1354
< <div class="item">This is the new item that was created</div>
小开

I'd forgo sending anything in the body of the response. Just set Location: to the (full) URL of the newly created resource.

Your description suggests that this is exactly the semantics you:

  1. POST a thing to create it
  2. Respond with enough to know two things:
    1. That the creation happened (the 201)
    2. Where to find the new thing (the Location header)

Anything else is superfluous.


提交答案