[java] @QueryParam과 @PathParam을 사용하는 경우

: 난 이미 여기에 요청합니다 질문 요구 하진 않았어
@PathParam과 @QueryParam의 차이점은 무엇입니까

이것은 “모범 사례”또는 컨벤션 질문입니다.

당신은 언제 사용하는 것이 @PathParam@QueryParam.

결정이 정보 패턴을 차별화하기 위해 두 가지를 사용하고 있다고 생각할 수 있습니다. LTPO 아래에서 완벽하게 관찰하는 것보다 덜 설명하겠습니다.

PathParam 사용은 정보 카테고리를 위해 예약 될 수 있는데, 이는 정보 트리의 분기에 잘 들어 맞습니다. PathParam을 사용하여 엔티티 클래스 계층으로 드릴 다운 할 수 있습니다.

반면, QueryParam은 클래스의 인스턴스를 찾기 위해 속성을 지정하기 위해 예약 될 수 있습니다.

예를 들어

  • /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) ;

나는 그것을하는 표준 규칙이 없다고 생각합니다. 있습니까? 그러나 사람들이 PathParam과 QueryParam을 사용하여 위에서 설명한 것처럼 정보를 차별화하는 방법에 대해 듣고 싶습니다. 또한 연습의 이유를 듣고 싶습니다.



답변

REST는 표준이 아니지만 일반적인 REST 문서 및 블로그 게시물을 읽으면 API URL을 구성하는 좋은 방법에 대한 지침을 제공해야합니다. 대부분의 나머지 API는 경로에 리소스 이름과 리소스 ID 만있는 경향이 있습니다. 같은 :

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

일부 REST API는 필터링, 페이지 매김 및 정렬을 위해 쿼리 문자열을 사용하지만 REST는 엄격한 표준이 아니므로 githubstackoverflow 와 같은 일부 REST API를 확인하고 사용 사례에 적합한 것이 무엇인지 확인하는 것이 좋습니다 .

경로에 필요한 매개 변수를 넣는 것이 좋습니다. 선택적 매개 변수는 반드시 쿼리 문자열 매개 변수 여야합니다. 경로에 선택적 매개 변수를 넣으면 다른 조합과 일치하는 URL 처리기를 작성하려고 할 때 실제로 혼란스러워집니다.


답변

이것이 제가하는 것입니다.

id를 기준으로 레코드를 검색하는 시나리오가있는 경우, 예를 들어 id가 15 인 직원의 세부 사항을 가져와야하는 경우 @PathParam을 사용하여 자원을 가질 수 있습니다.

GET /employee/{id}

한 번에 10 명만 모든 직원의 세부 정보를 가져와야하는 시나리오가있는 경우 쿼리 매개 변수를 사용할 수 있습니다

GET /employee?start=1&size=10

이것은 직원 ID 1을 시작하면 10 개의 레코드를 얻습니다.

요약하면 id를 기반으로 검색 할 때 @PathParam을 사용하십시오. 필터에 대한 사용자 @QueryParam 또는 사용자가 전달할 수있는 고정 옵션 목록이있는 경우


답변

매개 변수가 특정 엔티티를 식별하면 경로 변수를 사용해야한다고 생각합니다. 예를 들어, 내 블로그의 모든 게시물을 얻으려면 요청합니다.

GET: myserver.com/myblog/posts

id = 123 인 게시물을 얻으려면 요청합니다.

GET: myserver.com/myblog/posts/123

하지만 내 게시물 목록을 필터링하고 2013 년 1 월 1 일 이후 모든 게시물을 받으려면 요청합니다.

GET: myserver.com/myblog/posts?since=2013-01-01

첫 번째 예에서 “게시물”은 특정 엔티티 (블로그 게시물의 전체 모음)를 식별합니다. 두 번째 예에서 “123”은 특정 엔티티 (단일 블로그 게시물)도 나타냅니다. 그러나 마지막 예에서 “since = 2013-01-01″매개 변수는 특정 엔티티가 아닌 게시물 콜렉션을 필터링하는 요청입니다. 페이지 매김 및 순서는 또 다른 좋은 예입니다.

GET: myserver.com/myblog/posts?page=2&order=backward

희망이 도움이됩니다. 🙂


답변

필자는 개인적으로 “사용자가 이러한 매개 변수가 포함 된 URL을 책갈피에 추가 한 다음 PathParam을 사용하는 것이 합리적”인 방법을 사용했습니다.

예를 들어, 사용자 프로필의 URL에 일부 프로필 ID 매개 변수가 포함되어 있으면 사용자가 북마크하거나 전자 메일을 보낼 수 있으므로 해당 프로필 ID를 경로 매개 변수로 포함시킵니다. 또한 이것에 대한 또 다른 중요한 점은 경로 매개 변수를 포함하는 URL로 표시된 페이지가 변경되지 않는다는 것입니다. 사용자는 자신의 프로필을 설정하고 저장 한 다음 그 위치에서 많이 변경하지 않을 것입니다. 이는 웹 크롤러 / 검색 엔진 / 브라우저 / 등이 경로를 기반으로이 페이지를 멋지게 캐시 할 수 있음을 의미합니다.

URL에 전달 된 매개 변수가 페이지 레이아웃 / 컨텐츠를 변경할 가능성이있는 경우이를 queryparam으로 사용합니다. 예를 들어 프로필 URL이 사용자 전자 메일을 표시할지 여부를 지정하는 매개 변수를 지원하는 경우 쿼리 매개 변수로 간주합니다. (물론 &noemail=1매개 변수 매개 변수를 경로 매개 변수로 사용할 수 있으며 전자 메일 이 있거나 하나가없는 두 개의 별도 페이지를 생성하지만 논리적으로는 그렇지 않습니다. 특정 속성이 있거나없는 동일한 페이지입니다.

이것이 도움이되기를 바랍니다-설명이 약간 희미 할 수 있음을 이해합니다


답변

필터링에 쿼리 매개 변수를 사용하고 그룹화에 경로 매개 변수를 사용할 수 있습니다. 다음 링크는 pathParams 또는 QueryParams 사용시기에 대한 정보를 제공합니다.


답변

매우 흥미로운 질문입니다.

두 가지를 모두 사용할 수 있지만이 주제에 대한 엄격한 규칙은 없지만 URI 경로 변수를 사용하면 몇 가지 장점이 있습니다.

  • 캐시 : 인터넷상의 대부분의 웹 캐시 서비스는 쿼리 매개 변수가 포함되어있을 때 GET 요청을 캐시하지 않습니다. 서버에서 데이터를 변경하기 위해 GET 요청을 사용하는 RPC 시스템이 많기 때문에 (실패해야합니다! Get은 안전한 방법이어야합니다)

그러나 경로 변수를 사용하면이 모든 서비스가 GET 요청을 캐시 할 수 있습니다.

  • 계층 : 경로 변수는 계층을 나타낼 수 있습니다 : / City / Street / Place

사용자에게 데이터 구조에 대한 추가 정보를 제공합니다.

그러나 데이터에 계층 관계가 없으면 쉼표 또는 세미콜론을 사용하여 여전히 경로 변수를 사용할 수 있습니다.

/ 도시 / 경도, 위도

일반적으로 매개 변수의 순서가 중요 할 때는 쉼표를 사용하고 순서가 중요하지 않은 경우 세미콜론을 사용하십시오.

/ IconGenerator / 빨강; 파랑; 녹색

이러한 이유 외에도 쿼리 문자열 변수를 사용하는 것이 매우 일반적인 경우가 있습니다.

  • HTML 양식 변수를 URI에 자동으로 넣으려면 브라우저가 필요할 때
  • 알고리즘을 다룰 때. 예를 들어 Google 엔진은 쿼리 문자열을 사용합니다.

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

요약하자면,이 방법 중 하나를 사용해야 할 강력한 이유는 없지만 가능하면 URI 변수를 사용하십시오.


답변

앞서 언급했듯이 REST는 표준이 아닙니다. 그러나 표준 기반 URI 규칙을 구현하려는 경우 oData URI 규칙을 고려할 수 있습니다 . Ver 4는 OASIS 표준 으로 승인되었으며 Apache Olingo를 통한 Java를 포함한 다양한 언어의 oData 라이브러리가 있습니다 . 레드햇, 시트릭스, IBM, 블랙 베리, 드루팔, 넷플릭스 페이스 북, SAP 등 다른 업계의 지원을 받기 때문에 Microsoft의 산란 사실을 잊지 마십시오.

더 많은 채택자가 여기에 나열됩니다