Sempre aconselhável fazer uma função handler de response. Eu curto sempre usar o HATEOAS para tornar a RESTful de fato... Pesquisa sobre error handler left/right, muito bom para os retornos e tratamentos de exceções.

eu gosto de retornar o código do status da requisição, para facilitar na chamada no front, e em algums tipos de requisição, como um post, gosto de retornar um json com um retorno, nem que seja um OK

Sobre o DELETE, eu faria exatamente como você mencionou, comparando o ID do usuário do JWT com o ID enviado na URL. Já vi pessoas com receio desse tipo de comparação por conta do JWT ser "visível" para o usuário (não diretamente, mas um curioso consegue ver ele no localStorage ou nas chamadas às APIs pelo DevTools do Chrome, por exemplo), mas como a estrutura dele envolve assinatura e etc, acaba sendo mais difícil de realmente comprometer a integridade dele, mesmo se alguém mudar o payload que é um simples base64. Se o seu back-end faz a validação certa do JWT, pode pegar as informações dele sem medo. Então, no seu caso, particularmente eu acho válido comparar o ID que vem no JWT com o ID informado na URL pra saber se o usuário tá fazendo "usuarisse" ou não kk Sobre o código de retorno, eu particularmente não costumo retornar ele no corpo da resposta, justamente porque ele já vem informado nos cabeçalhos das respostas (por exemplo, usando alguma biblioteca de ajax - como Axios, ou até mesmo a Fetch API, que não é uma biblioteca mas tem tudo que é necessário -, já é possível validar o código de status de uma request), então seria um tipo de redundância. Assim, você pode deixar o corpo da resposta somente com o dado que precisar retornar. E, em casos de erro, por exemplo, eu costumo retornar apenas um objeto`{message:"Mensagem descrevendo o erro"}` no body, assim posso mostrar alguma informação útil para o usuário, e não preciso deixar regra de negócio (como validar o motivo do erro) no front-end, porque o próprio back-end já vai me trazer uma mensagem descrevendo o que deu errado.

Eu particulamente gosto de devolver um json padronizado com algumas informações relevantes, como status da requisição, campo de erros, informações sbre paginação e outras informações relevantes. Uma boa API facilita muito a vida do front, geralmente, faço algo como o exemplo abaixo, imaginando um endpoint que devolveria uma lista de livros: ```json { "data": [ { "id": 1, "nome": "Entendendo algoritmos", } ... ], "meta": { "total": 1, "perPage": 10, "currentPage": 0, "nextPage": 1, "lastPage": null, "nextPageUrl": ... }, "error" : { "message": (alguma mensagem significativa para poder ser exibida no front), "debugMessage": (alguma mensagem que ajudasse a compreender a raíz do erro), "subErrors": [(em caso de múltiplos erros)], } } ```