GabaritoA — /clientes/123/pedidos/456
Gabarito: letra A. A alternativa A (/clientes/123/pedidos/456) segue as melhores práticas REST: usa substantivos (recursos), hierarquia natural (clientes → pedidos), e identifica recursos por IDs na path, sem verbos ou query strings. As demais alternativas violam os princípios de interface uniforme e identificação de recursos por URI.
A banca testa o entendimento de que, em APIs RESTful, URIs representam recursos (substantivos), não ações (verbos). Os métodos HTTP (GET, POST, PUT, DELETE) são as operações. Parâmetros de consulta (query string) são para filtros/paginação, não para identificar um recurso específico — isso deve estar na path.
A URI /clientes/123/pedidos/456 representa um recurso "pedido" aninhado a "cliente", com identificadores numéricos na path. É uma representação limpa, hierárquica e sem verbos — exemplo clássico de design RESTful.
/obterCliente?id=123 contém o verbo "obter" e usa query string para identificar o recurso. Em REST, o verbo está implícito no método HTTP (GET); a URI deve nomear o recurso, não a ação. O correto seria /clientes/123.
/clientes/id=123 mistura path com sintaxe de query (id=123). Não é uma forma padrão. O ID deve ser parte da path: /clientes/123.
/GetPedido?id=456&cliente=123 contém verbo "Get" e usa query string para ambos os parâmetros. Novamente, viola: recursos devem ser substantivos, e a identificação deve estar na path: /pedidos/456 ou /clientes/123/pedidos/456.
/clientes/obter/123 contém verbo "obter" na path. Ações não devem estar na URI; deve ser /clientes/123.
A banca troca verbos por substantivos nas URIs – o candidato é induzido a escolher opções que descrevem a ação ("obter", "Get") em vez do recurso. Lembre-se: URI = recurso; método HTTP = ação. Com treino, essa troca é fácil de detectar 💪
Gabarito: letra A — a única URI que segue as convenções RESTful.
Link permanente: /questoes/gp045405