Origem: Wikipedia: Uniform Resource Locator
Um caminho , que contém dados, geralmente organizados em forma hierárquica , que aparece como uma sequência de segmentos separados por barras.
Uma consulta opcional , separada da parte anterior por um ponto de interrogação (?), Contendo uma sequência de consulta de dados não hierárquicos .
- De acordo com o design conceitual da URL, podemos implementar um PathParam para componentes hierárquicos de dados / diretivas / localizadores ou implementar um QueryParam quando os dados não são hierárquicos. Isso faz sentido porque os caminhos são naturalmente ordenados, enquanto as consultas contêm variáveis que podem ser ordenadas arbitrariamente (pares de variáveis / valores não ordenados).
Um comentarista anterior escreveu:
Eu acho que se o parâmetro identifica uma entidade específica, você deve usar uma variável de caminho.
Outro escreveu,
Use @PathParam para recuperação com base no ID. Usuário @QueryParam para filtro ou se você tiver alguma lista fixa de opções que o usuário possa passar.
Outro,
Eu recomendo colocar quaisquer parâmetros necessários no caminho, e quaisquer parâmetros opcionais certamente devem ser parâmetros de string de consulta.
- No entanto, pode-se implementar um sistema flexível e não hierárquico para identificar entidades específicas! Pode-se ter vários índices exclusivos em uma tabela SQL e permitir que as entidades sejam identificadas usando qualquer combinação de campos que compõem um índice exclusivo! Diferentes combinações (talvez também ordenadas de forma diferente) podem ser usadas para links de várias entidades relacionadas (referenciadores). Nesse caso, podemos estar lidando com dados não hierárquicos, usados para identificar entidades individuais - ou em outros casos, apenas especificar determinadas variáveis / campos - certos componentes de índices exclusivos - e recuperar uma lista / conjunto de registros. Nesses casos, pode ser mais fácil, mais lógico e razoável implementar os URLs como QueryParams!
Uma string hexadecimal longa poderia diluir / diminuir o valor das palavras-chave no restante do caminho? Pode valer a pena considerar as possíveis implicações de SEO da colocação de variáveis / valores no caminho ou na consulta, e as implicações da interface humana para que os usuários possam atravessar / explorar a hierarquia de URLs editando o conteúdo da barra de endereço. Minha página 404 não encontrada usa variáveis SSI para redirecionar automaticamente URLs quebrados para seus pais! Os robôs de pesquisa também podem atravessar a hierarquia do caminho. Por outro lado, pessoalmente, quando compartilho URLs nas mídias sociais, retiro manualmente quaisquer identificadores exclusivos privados - normalmente truncando a consulta a partir da URL, deixando apenas o caminho: nesse caso, existe alguma utilidade na colocação de identificadores exclusivos no caminho e não na consulta. Se queremos facilitar o uso de componentes de caminho como uma interface de usuário grosseira, talvez dependa se os dados / componentes são legíveis por humanos ou não. A questão da legibilidade humana relaciona-se um pouco à questão da hierarquia: freqüentemente, os dados que podem ser expressos como palavras-chave legíveis por humanos também são hierárquicos; enquanto os dados hierárquicos geralmente podem ser expressos como palavras-chave legíveis por humanos. (Os próprios mecanismos de pesquisa podem ser definidos como aumentando o uso de URLs como uma interface do usuário.) Hierarquias de palavras-chave ou diretivas podem não ser estritamente ordenadas, mas geralmente são próximas o suficiente para cobrir casos alternativos no caminho, erotule uma opção como o caso "canônico" .
Existem basicamente vários tipos de perguntas que poderíamos responder com o URL para cada solicitação:
- Que tipo de registro / coisa estamos solicitando / servindo?
- Em qual (s) interessado (s)?
- Como queremos apresentar as informações / registros?
Q1 é quase certamente melhor coberto pelo caminho ou pelo PathParams. Q3 (provavelmente controlado por meio de um conjunto de parâmetros opcionais e valores padrão ordenados arbitrariamente); é quase certamente melhor coberto por QueryParams. P2: Depende ...