Generally, the issuer (e.g. the html client) would receive the confirmation (e.g. 202 accepted) and take the decision on how to render the result.
It could be the web client decides at that point to refresh, or fetches a new list and re-renders using dynamic HTML techniques -- depending on the complexity of the web site, either is fine.
You're right though, this should not be done on the server side -- future apps may not have an HTML rendering -- e.g. system integrations or native mobile apps.
In these cases, I like to return a payload that gives the client a hint on what to do next. E.g. I might include something like:
200 OK
{
"message": "delete id xxx completed",
"_next": "https://my-server.com/api/items"
}
It helps developers in the future decide how to proceed.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…