javascript - REST API删除请求并更新分页(REST API Delete request and update pagination)

Question

I have a question regarding the DELETE endpoint in my REST API.(我对REST API中的DELETE端点有疑问。)

To give a bit of context, in my frontend I have a 'clients' table with serverside pagination, so whenever I change page I send a request to the server which returns an object like the following:(为了说明背景，在我的前端，我有一个带有服务器端分页的“客户”表，因此，每当我更改页面时，我都会向服务器发送一个请求，该请求返回如下对象：)

{
    "items": [{id: 1, name: 'foo'}, {id: 2, name: 'bar'}, {id: 3, name: 'buzz'}],
    "itemCount": 3,
    "totalItems": 56,
    "pageCount": 19,
    "next": "http://localhost:3000/api/clients?page=2&limit=3",
    "previous": "",
    "currentPage": 1
}

When I delete or modify a client, I would like to return an updated version of the clients list, but I'm not sure whats the best way to do this without sending information on the page and limit per page .(当我删除或修改客户端时，我想返回客户端列??表的更新版本，但是我不确定在不发送页面信息和每页 限制的情况下实现此目的的最佳方法是什么。)

The solutions I thought of to solve this issue are:(我想到的解决方案是：)

• I could send the information of the page and limit per page with the requests and retrieve the information in my delete endpoint after deleting the client.(删除客户端后，我可以发送页面信息并限制每个页面的请求，并在我的删除端点中检索信息。)

  However, this seems very inefficient because I would be adding this extra info to endpoints not only for clients but for other models as well, as I have the same issue with products for example.(但是，这似乎效率很低，因为我会将这些额外的信息不仅添加到客户端，还添加到其他模型的端点，例如，我在产品方面也遇到了同样的问题。)

• I could send a delete request on my frontend and when that finishes make a request to get the updated information separately (maybe even in parallel?).(我可以在前端发送删除请求，完成后再发出请求以分别获取更新的信息（甚至可以并行获取）。)

  But this seems inefficient as well due to the extra network request.(但是由于额外的网络请求，这似乎效率也很低。)

What would be the best way to go about this problem?(解决此问题的最佳方法是什么？)

  ask by Showner91 translate from so

Answer 1

Interesting question.(有趣的问题。)

I would recommend sending another GET /clients request to fetch the updated data rather than relying on the DELETE endpoint to give you that data.(我建议发送另一个GET /clients请求以获取更新的数据，而不是依赖DELETE端点为您提供该数据。) That way, you keep your GET and DELETE logic separate and you don't have to repeat yourself in the code of your API.(这样，您就可以将GET和DELETE逻辑分开，而不必在API代码中重复。)

This approach might seem wasteful but it also feels cleaner and can be leveraged by the consumers of your API to programmatically refetch data a la GraphQL/Apollo ( https://www.apollographql.com/docs/react/data/queries/#refetching ).(这种方法可能看起来很浪费，但也感觉更干净，可以被您的API使用者用来以编程方式通过GraphQL / Apollo重新获取数据（ https://www.apollographql.com/docs/react/data/queries/#refetching ）。)

If you are concerned about performances, you can also add caching to your API (with node-cache , for example: https://www.npmjs.com/package/node-cache or AWS Redis: https://aws.amazon.com/redis/ ) to send responses faster for previously seen queries.(如果你正在关注的表演，你还可以添加缓存到您的API（与node-cache ，例如： https://www.npmjs.com/package/node-cache或AWS的Redis： HTTPS：//aws.amazon .com / redis / ）以更快地发送响应给先前查看的查询。)

There is no REST API standard but, from experience, it is pretty common for DELETE endpoints to be as stateless as possible and return an empty body with a status code of 204 (see https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#http-status ).(没有REST API标准，但是从经验来看， DELETE端点尽可能无状态并返回状态码为204的空主体是很常见的（请参阅https://www.vinaysahni.com/best-practices -for a pragmatic-restful-api＃http-status ）。)

Hope it helps!(希望能帮助到你！)

Keep up with the good work :)(跟上好工作:))