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.

I have been told issuing a redirect('/') for API requests is not RESTful. I have been doing it like so:

app.delete('/items/:id', urlencodedParser, (req, res) => {
    let index = parseInt(req.params.id);
    items.splice(index, 1);

    res.redirect('/');
});

I now know this is wrong. But then what do I need to do to update the content on the HTML web page without refreshing the page manually?