REST API - should I request the whole list afetr updating a single entity? -

i have web app, client , server communicate via rest api. on server have urls like

• get /api/items/list - return list of items
• post /api/items - insert new item
• etc

there no pagination, items displayed on client @ once.

the question - after client inserts new item, should request whole list server or add entity local collection?

why yes:

• if items sorted, adding new item breaks sorting. it's easier updated list server, sort on client.
• the list might have been updated else. yet, refreshing list after modification alleviates situation bit, not solves it.

why no:

• two requests per 1 user action means user should wait twice longer, can problem if internet connection slow.

i believe, can done 1 request should done 1 request. missing something?

as things in software, depends, on user requirements are, if of them conflicting , if so, 1 takes priority.

the first thing wonder "/api/items/list" endpoint retrieving different hitting "/api/items". different representation, maybe fields etc.. fine, if sorting consider simple sorting fields client side concern , implement sorting there.

my reasons potentially improve performance caching of /api/items/list since hitting resource warm cache else along route, regardless of how want sorted. naturally set cache interval suitable value.

if consider point of view of adding new field item resource. able implement "sorting" on new field without client update well? rather more difficult allowing client control sorting of data.

with regards being aware of concurrent updates list, again depending on whether want millisecond updates (probably shouldn't using http if true requirement) or if few seconds fine. if system wants able check list has been updated 5 seconds, implement endpoint can polled see if collection has been updated or not, , retrieve list if has. again, if caching implemented, chances in multi-user environment else might have been watching same collection , has warmed cache you, saving round trip server.

if item resources have "last modified" field, quite easy implement resource [get] "/api/items/modifiedtimes/latest" represents recent modifiedtime of whatever server considers latest resource. if worried 2 updates occuring same timestamp, use same concept solve different way.

in summary, if using http it's goodness such caching, worrying overhead of 2 round trips versus 1 server isn't worth considering, unless, again depends. if latency , performance issue, in direct contention requirement server side sorting , need compromise.

post item collection, server should return created no body. on client add item collection , reapply sort. in parallel have polling latest endpoint check if collection has changed, , list if has.

as aside, if really worried performance, might consider instead of polling latest endpoint time, having event endpoint poll can return list of events have occurred on collection (insert, update, delete) along payload each event required. "/api/items/events?since=2017082215005959" use result update client list needed.

wiki