我有一个web应用程序，客户端和服务器通过REST API进行通信。在服务器上，我有类似的URLS
- GET/api/items/list-返回项目列表
- POST/api/items-插入新项
- 等等
没有分页，所有项目都会同时显示在客户端上。
问题是，在客户端插入一个新项目后，它应该从服务器请求整个列表，还是只是将实体添加到本地集合？
为什么是：
- 如果项目已排序，则添加新项目会中断排序。从服务器获取更新的列表比在客户端排序更容易
- 该列表可能已由其他人更新。然而，在对列表进行任何修改后刷新列表可以稍微缓解这种情况，但不能解决问题
为什么不：
- 每个用户操作两个请求意味着用户应该再等待两次，如果互联网连接缓慢，这可能会成为一个问题
我认为，用一个请求可以做的事情应该用一个要求来做。我是不是错过了什么？
与软件中的大多数东西一样，这主要取决于您的用户需求是什么，它们中是否有冲突，如果有，哪一个优先。
我想知道的第一件事是，"/api/items/list"端点检索与只点击"/api/items"不同。这是不是一种不同的表示，可能只有某些字段等。这很好，但如果只是为了排序，那么我会认为任何简单的按字段排序都是客户端关注的问题，并在那里实现我的排序。
我这样做的原因可能是通过缓存/api/items/list来提高性能，因为任何访问该资源的人都会为沿途的其他人预热缓存，无论他们希望如何排序。当然，您会将缓存间隔设置为一个合适的值。
如果您从向项目资源添加新字段的角度来考虑它。你能在没有客户端更新的情况下对新字段执行"排序"吗？您可以，但这比简单地允许客户端控制数据的排序要困难得多。
关于注意列表的并发更新，同样取决于您是想要毫秒级更新(如果这是真正的要求，可能不应该使用HTTP)还是几秒钟就可以了。如果您的系统只想在5秒内检查列表是否已更新，请实现一个端点，该端点可以被轮询以查看集合是否已更新；如果已更新，则检索列表。同样，如果实现了缓存，那么在多用户环境中，其他人可能也在观看同一个集合，并且刚刚为您预热了缓存，为您节省了往返服务器的时间。
如果项目资源有一个"上次修改"字段，那么很容易实现像[GET]"/api/items/modifiedTimes/latest"这样的资源，它表示服务器认为是最新资源的最新修改时间。如果你担心两个时间戳完全相同的更新，那么使用相同的概念，但用不同的方法解决。
总之，如果您使用的HTTP具有缓存等所有优点，那么担心两次往返与一次到服务器的开销是不值得考虑的，除非这再次取决于情况。如果延迟和性能真的是一个问题，那么它与服务器端排序的需求直接冲突，您需要妥协。
将项目POST到集合中，服务器应返回Created而不带正文。在客户端上，将您的项目添加到集合中，并重新应用排序。同时，让一些东西轮询最新的端点，以检查集合是否已更改，如果已更改，则获取列表。
顺便说一句，如果您真的很担心性能，您可能会考虑不随时间轮询最新的端点，而是使用一个要轮询的事件端点，该端点可以向您返回集合上发生的事件列表(插入、更新、删除)，以及所需的每个事件的有效负载。类似于"/api/items/events？since=2017082215005959"您可以根据需要使用此结果来更新您的客户端列表。
如果您担心网络负载，并且列表很小，请增强资源，以便GET响应提供Last Modified。
对于POST请求，根据If Modified Since标头(列表的Last Modified的客户端值)来增加响应。如果服务器通过If Modified Since检测到POST不同步，则更新并返回正文中的列表，否则更新将返回一个空正文，在这种情况下，新项在本地管理，客户端代码处理排序。
无论哪种方式，POST响应都必须返回当前的Last Modified。