pathparam - queryparams java



Quando usar @QueryParam vs @PathParam (9)

  1. @QueryParam pode ser convenientemente usado com a anotação de valor padrão para que você possa evitar uma exceção de ponteiro nulo se nenhum parâmetro de consulta for passado.

Quando você deseja analisar parâmetros de consulta a partir de uma solicitação GET, basta definir o respectivo parâmetro para o método que manipulará a solicitação GET e anotá-los com a anotação @QueryParam

  1. @PathParam extrai os valores e combinações de URI para @Path . E, portanto, obtém o parâmetro de entrada. 2.1 @PathParam pode ser mais de um e está configurado para argumentos de métodos

    @Path("/rest")
    public class Abc {
    
        @GET
        @Path("/msg/{p0}/{p1}")
        @Produces("text/plain")
        public String add(@PathParam("p0") Integer param1, @PathParam("p1")  Integer param2 )
        {
            return String.valueOf(param1+param2);
        }
    } 

No exemplo acima,
http://localhost:8080/Restr/rest/msg/{p0}/{p1} ,
p0 corresponde ao param1 e p1 corresponde ao param2 . Então, para o URI
http://localhost:8080/Restr/rest/msg/4/6 ,
nós obtemos o resultado 10 .

No serviço REST, o JAX-RS fornece @QueryParam e @FormParam para aceitar dados da solicitação HTTP. Um formulário HTTP pode ser enviado por diferentes métodos, como GET e POST.

@QueryParam : aceita solicitação GET e lê dados da string de consulta.

@FormParam : aceita solicitação POST e busca dados do formulário HTML ou qualquer solicitação da mídia

Não estou fazendo a pergunta que já foi feita aqui: Qual é a diferença entre @PathParam e @QueryParam

Esta é uma das "melhores práticas" ou questão da convenção.

Quando você usaria @PathParam vs @QueryParam ?

O que posso pensar é que a decisão pode estar usando os dois para diferenciar o padrão de informação. Deixe-me ilustrar abaixo da minha LTPO - menos que perfeita observação.

O uso de PathParam poderia ser reservado para a categoria de informação, que se encaixaria muito bem em uma ramificação de uma árvore de informações. PathParam pode ser usado para detalhar a hierarquia de classes de entidade.

Considerando que, QueryParam poderia ser reservado para especificar atributos para localizar a instância de uma classe.

Por exemplo,

  • /Vehicle/Car?registration=123
  • /House/Colonial?region=newengland

/category?instance

@GET
@Path("/employee/{dept}")
Patient getEmployee(@PathParam("dept")Long dept, @QueryParam("id")Long id) ;

vs /category/instance

@GET
@Path("/employee/{dept}/{id}")
Patient getEmployee(@PathParam("dept")Long dept, @PathParam("id")Long id) ;

vs ?category+instance

@GET
@Path("/employee")
Patient getEmployee(@QueryParam("dept")Long dept, @QueryParam("id")Long id) ;

Eu não acho que haja uma convenção padrão de fazer isso. Existe? No entanto, gostaria de saber como as pessoas usam o PathParam vs QueryParam para diferenciar suas informações como exemplificado acima. Eu também adoraria ouvir a razão por trás da prática.


Answer #1

É uma questão muito interessante.

Você pode usar ambos, não há nenhuma regra estrita sobre este assunto, mas usar variáveis ​​de caminho URI tem algumas vantagens:

  • Cache : a maioria dos serviços de cache da Web na Internet não faz cache da solicitação GET quando eles contêm parâmetros de consulta. Eles fazem isso porque há muitos sistemas RPC usando solicitações GET para alterar dados no servidor (falhar !! Obter deve ser um método seguro)

Mas se você usar variáveis ​​de caminho, todos esses serviços podem armazenar em cache suas solicitações GET.

  • Hierarquia : as variáveis ​​de caminho podem representar a hierarquia: / City / Street / Place

Ele fornece ao usuário mais informações sobre a estrutura dos dados.

Mas se seus dados não tiverem nenhuma relação hierárquica, você ainda poderá usar variáveis ​​Path, usando vírgula ou ponto e vírgula:

/ Cidade / longitude, latitude

Como regra, use vírgula quando a ordem dos parâmetros for importante, use ponto-e-vírgula quando a ordenação não tiver importância:

/ IconGenerator / vermelho; azul; verde

Além desses motivos, há alguns casos em que é muito comum usar variáveis ​​de string de consulta:

  • Quando você precisa do navegador para colocar automaticamente variáveis ​​de formulário HTML no URI
  • Quando você está lidando com algoritmo. Por exemplo, o mecanismo do Google usa strings de consulta:

http: // www.google.com/search?q=rest

Resumindo, não há nenhum motivo forte para usar um desses métodos, mas sempre que possível, use variáveis ​​de URI.


Answer #2

Como Theon observou, o REST não é um padrão. No entanto, se você estiver procurando implementar uma convenção de URI baseada em padrões, considere a convenção de URI do oData . A versão 4 foi aprovada como um padrão OASIS e existem bibliotecas para o oData para vários idiomas, incluindo Java via Apache Olingo . Não deixe que o fato de ser um spawn da Microsoft o afaste, já que ele também ganhou suporte de outras empresas do setor, como Red Hat, Citrix, IBM, Blackberry, Drupal, Netflix Facebook e SAP.

Mais adotantes estão listados aqui


Answer #3

Em poucas palavras,

@Pathparam trabalha para o valor que passa por ambos os recursos e a cadeia de consulta

  • / user / 1
  • / user? id = 1

@Queryparam funciona para passagem de valor apenas String de consulta

  • / user? id = 1

Answer #4

Eu estou dando um exapmle para undersand quando usamos @Queryparam e @pathparam

Por exemplo, eu estou tomando um resouce é carResource classe

Se você quiser tornar as entradas do seu método de recursos manejáveis, então use o tipo de parâmetro como @pathaparam , se as entradas do seu método de recurso devem ser opcionais, então mantenha esse tipo de parâmetro como @QueryParam param

@Path("/car")
class CarResource
{
    @Get
    @produces("text/plain")
    @Path("/search/{carmodel}")
    public String getCarSearch(@PathParam("carmodel")String model,@QueryParam("carcolor")String color) {
        //logic for getting cars based on carmodel and color
            -----
        return cars
    }
}

Para este recurso passar o pedido

req uri ://address:2020/carWeb/car/search/swift?carcolor=red

Se você der req como este o resouce dará o modelo de carro baseado e cor

 req uri://address:2020/carWeb/car/search/swift

Se você der o req como este o método do resoce indicará somente o carro baseado modelo rápido

req://address:2020/carWeb/car/search?carcolor=red

Se você der assim nós teremos a exceção ResourceNotFound porque na classe resouce do carro eu declarei carmodel como @pathPram que é você deve e deve dar o carmodel como reQ uri caso contrário ele não passará o req para resouce mas se você não passar a cor também passará o req para recurso porque porque a cor é @quetyParam é opcional em req.


Answer #5

Eu pessoalmente usei a abordagem de "se faz sentido para o usuário marcar um URL que inclua esses parâmetros e usar o PathParam".

Por exemplo, se o URL de um perfil de usuário incluir algum parâmetro de ID de perfil, uma vez que isso pode ser marcado pelo usuário e / ou enviado por e-mail, incluo esse ID de perfil como um parâmetro de caminho. Além disso, outro fator a considerar é que a página denotada pela URL que inclui o parâmetro path não muda - o usuário irá configurar seu perfil, salvá-lo e, em seguida, é improvável que mude muito a partir daí; Isso significa que os webcrawlers / mecanismos de pesquisa / navegadores / etc podem armazenar essa página em cache com base no caminho.

Se um parâmetro transmitido na URL provavelmente altere o layout / conteúdo da página, use-o como um queryparam. Por exemplo, se o URL do perfil oferecer suporte a um parâmetro que especifica se deve mostrar ou não o email do usuário, considero que seja um parâmetro de consulta. (Eu sei, sem dúvida, você poderia dizer que o &noemail=1 ou qualquer parâmetro que ele seja pode ser usado como um caminho param e gera 2 páginas separadas - uma com o e-mail nela, uma sem ele - mas logicamente essa não é a case: ainda é a mesma página com ou sem certos atributos mostrados.

Espero que isso ajude - eu aprecio a explicação pode ser um pouco difusa :)


Answer #6

REST pode não ser um padrão como tal, mas ler sobre a documentação geral do REST e as postagens do blog deve fornecer algumas diretrizes para uma boa maneira de estruturar os URLs da API. A maioria das APIs de descanso tendem a ter apenas nomes de recursos e IDs de recursos no caminho. Tal como:

/departments/{dept}/employees/{id}

Algumas APIs REST usam strings de consulta para filtragem, paginação e classificação, mas como o REST não é um padrão estrito, eu recomendaria verificar algumas APIs REST como github e e ver o que poderia funcionar bem para seu caso de uso.

Eu recomendaria colocar quaisquer parâmetros necessários no caminho e quaisquer parâmetros opcionais certamente seriam parâmetros de string de consulta. Colocar parâmetros opcionais no caminho acabará ficando muito confuso ao tentar criar manipuladores de URL que correspondam a combinações diferentes.


Answer #7

Você pode suportar parâmetros de consulta e parâmetros de caminho, por exemplo, no caso de agregação de recursos - quando a coleta de sub-recursos faz sentido por conta própria.

/departments/{id}/employees
/employees?dept=id

Parâmetros de consulta podem suportar subconjuntos hierárquicos e não hierárquicos; os parâmetros de caminho são apenas hierárquicos.

Recursos podem exibir várias hierarquias. Suportar caminhos curtos se você estiver consultando sub-coleções amplas que cruzam limites hierárquicos.

/inventory?make=toyota&model=corolla
/inventory?year=2014

Use parâmetros de consulta para combinar hierarquias ortogonais.

/inventory/makes/toyota/models/corolla?year=2014
/inventory/years/2014?make=toyota&model=corolla
/inventory?make=toyota&model=corolla&year=2014

Use apenas parâmetros de caminho no caso de composição - quando um recurso não faz sentido divorciado de seu pai, e a coleção global de todos os filhos não é um recurso útil em si.

/words/{id}/definitions
/definitions?word=id   // not useful

Answer #8

Da Wikipedia: Localizador Uniforme de Recursos

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 cadeia de consulta de dados não hierárquicos .

- De acordo com o design conceitual da URL, podemos implementar um PathParam para componentes hierárquicos data / directives / locator, 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 filtrar ou se você tiver qualquer lista fixa de opções que o usuário possa passar.

Outro,

Eu recomendaria colocar quaisquer parâmetros necessários no caminho e quaisquer parâmetros opcionais certamente seriam 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! Um pode ter vários índices exclusivos em uma tabela SQL e permitir que entidades sejam identificadas usando qualquer combinação de campos que inclua um índice exclusivo! Combinações diferentes (talvez também ordenadas diferentemente) 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 - determinados 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 as 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 de colocar variáveis ​​/ valores no caminho, ou na consulta , e as implicações da interface humana se queremos que os usuários possam percorrer / explorar a hierarquia de URLs editando o conteúdo de a barra de endereços. 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 percorrer a hierarquia de caminho. Por outro lado, pessoalmente, quando compartilho URLs em mídias sociais, removo manualmente todos os identificadores exclusivos privados - normalmente truncando a consulta a partir do URL, deixando apenas o caminho: nesse caso, há algum utilitário para colocar identificadores exclusivos no caminho, e não na consulta. Se queremos facilitar o uso de componentes de caminho como uma interface de usuário crua, 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 com a questão da hierarquia: muitas vezes, os dados que podem ser expressos como palavras-chave legíveis por humanos também são hierárquicos; enquanto os dados hierárquicos podem frequentemente 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 e rotular um opção como o caso "canônico" .

Existem basicamente vários tipos de perguntas que podemos responder com o URL para cada solicitação:

  1. Que tipo de registro / coisa estamos solicitando / servindo?
  2. Em qual (is) interesse (s)?
  3. Como queremos apresentar as informações / registros?

Q1 é quase certamente melhor coberto pelo caminho, ou por PathParams. Q3 (que provavelmente é controlado através de um conjunto de parâmetros opcionais arbitrariamente ordenados e valores padrão); é quase certamente melhor coberto por QueryParams. Q2: depende ...





jax-rs