Estou desenvolvendo um serviço REST e estou tentando seguir as convenções e diretrizes do doutor Roy Fielding.

Imagino meu serviço como um ponto final que expõe um conjunto de recursos. Um recurso é identificado por um URI e os clientes da API podem manipular recursos usando semântica HTTP (ou seja, diferentes verbos HTTP são mapeados para as operações correspondentes nos URIs).

As diretrizes afirmam que esses URIs devem ser definidos de maneira hierárquica, refletindo a hierarquia de objetos. Isso é útil na criação de recursos, porque no back-end precisamos dos dados para executar a operação de criação. No entanto, em outras manipulações, muitas das informações incluídas no URI nem sequer serão usadas pelo serviço, porque geralmente o ID do recurso por si só é suficiente para identificar exclusivamente o destino da operação.

Um exemplo: considere uma API que expõe a criação e o gerenciamento de produtos. Considere também que um produto está associado a uma marca. Na criação, faz sentido que a seguinte ação seja executada: HTTP POST / Brand / {brand_id} / Produto [Corpo que contém a entrada necessária para a criação do produto]

A criação retorna um HTTP 201 criado com um cabeçalho de localização que expõe a localização do produto recém-criado.

Em outras manipulações, os clientes podem acessar o produto executando: HTTP PUT / Brand / {brand_id} / Produto / {product_id} HTTP DELETE / Brand / {brand_id} / Produto / {product_id} etc

No entanto, como o ID do produto é universal no escopo do produto, as seguintes manipulações podem ser executadas assim: / Product / {product_id} Eu apenas mantenho o prefixo / Brand / {brand_id} por motivos de coerência. De fato, o ID da marca está sendo ignorado pelo serviço. Você acha que essa é uma boa prática e é razoável para manter uma definição clara e inequívoca de ServiceInterface? Quais são os benefícios de fazer isso e esse é o caminho a seguir?

Além disso, qualquer ponteiro sobre as melhores práticas de definição de URI seria apreciado.

desde já, obrigado