이것은 이 질문에 대한 보다 일반적인 재구성입니다 (Rails 관련 부분을 제거함).
RESTful 웹 응용 프로그램의 리소스에서 페이지 매김을 구현하는 방법을 잘 모르겠습니다. 내가이라는 리소스를 가지고 있다고 가정하면 products다음 중 어떤 것이 가장 좋은 방법이라고 생각합니까?
1. 쿼리 문자열 만 사용
예. http://application/products?page=2&sort_by=date&sort_how=asc
여기서 문제는 전체 페이지 캐싱을 사용할 수 없으며 URL이 매우 깨끗하고 기억하기 쉽지 않다는 것입니다.
2. 정렬을 위해 페이지를 리소스 및 쿼리 문자열로 사용
예. http://application/products/page/2?sort_by=date&sort_how=asc
이 경우에 볼 수있는 문제는 http://application/products/pages/1사용 sort_by=price하면 완전히 다른 결과를 얻을 수 있고 여전히 페이지 캐싱을 사용할 수 없기 때문에 고유 한 리소스 가 아니라는 것입니다.
3. 페이지를 리소스로 사용하고 정렬을위한 URL 세그먼트
예. http://application/products/by-date/page/2
개인적 으로이 방법을 사용하는 데 아무런 문제가 없지만 누군가는 이것이 좋은 방법이 아니라고 경고했습니다 (그는 이유를주지 않았 으므로 권장하지 않는 이유 를 알고 있다면 알려주십시오)
모든 제안, 의견, 비평은 환영 이상입니다. 감사.
답변
버전 3의 문제는 “관점”문제라고 생각합니다. 페이지에서 페이지를 리소스 또는 제품으로 보십니까?
페이지를 리소스로 볼 경우 2 페이지에 대한 쿼리는 항상 2 페이지를 생성하므로 완벽하게 훌륭한 솔루션입니다.
그러나 페이지의 제품을 리소스로 볼 경우 2 페이지의 제품이 변경 될 수있는 문제 (오래된 제품이 삭제되거나 기타)가 발생하는 경우 URI가 항상 동일한 리소스를 반환하지는 않습니다.
예를 들어, 고객이 제품 목록 페이지 X에 대한 링크를 저장하고 다음에 링크를 열면 해당 제품이 더 이상 X 페이지에 없을 수 있습니다.
답변
Fionn에 동의하지만 한 단계 더 나아가 페이지가 리소스 가 아니라 요청의 속성 이라고 말합니다 . 따라서 옵션 1 쿼리 문자열 만 선택했습니다. 기분이 좋아. Twitter API 가 편안하게 구성되는 방식이 정말 좋습니다. 너무 간단하지도 않고 복잡하지도 않으며 문서화가 잘되어 있습니다. 더 좋든 나쁘 든 내가 어떤 방식 으로든 다른 방식으로 무언가를 할 때 울타리에있을 때 “가는”디자인입니다.
답변
HTTP에는 페이지 매김에 적합한 Range 헤더가 있습니다. 보낼 수 있습니다
Range: pages=1
첫 페이지 만 갖습니다. 페이지가 무엇인지 다시 생각해야 할 수도 있습니다. 클라이언트가 다른 범위의 항목을 원할 수도 있습니다. 범위 헤더는 주문을 선언하기 위해 작동합니다.
Range: products-by-date=2009_03_27-
해당 날짜보다 최신의 모든 제품을 얻거나
Range: products-by-date=0-2009_11_30
해당 날짜보다 오래된 모든 제품을 가져옵니다. ‘0’은 아마도 최상의 솔루션은 아니지만 RFC는 범위 시작을 위해 무언가를 원하는 것 같습니다. units = -range_end를 구문 분석하지 않는 HTTP 구문 분석기가 배치되었을 수 있습니다.
헤더가 (허용 가능한) 옵션이 아닌 경우 첫 번째 솔루션 (모두 쿼리 문자열)은 페이지를 처리하는 방법입니다. 그러나 쿼리 문자열 (알파벳 순서로 정렬 (키 = 값) 쌍)을 정규화하십시오. “? a = 1 & b = x”및 “? b = x & a = 1″미분 문제를 해결합니다.
답변
옵션 1은 응용 프로그램에서 페이지 매김을 동일한 리소스의 다른보기를 생성하는 기술로 보는 범위에서 가장 좋습니다.
그러나 URL 체계는 상대적으로 중요하지 않습니다. 모든 REST 애플리케이션이 정의에 따라야하므로 애플리케이션을 하이퍼 텍스트 방식 으로 설계하는 경우 클라이언트가 자체적으로 URI를 구성하지 않습니다. 대신 응용 프로그램에서 클라이언트에 대한 링크를 제공하고 클라이언트가 해당 링크를 따릅니다.
고객이 제공 할 수있는 링크 중 하나는 페이지 매김 링크입니다.
이 모든 것의 유쾌한 부작용은 페이지 매김 URI 구조에 대해 마음이 바뀌고 다음 주에 완전히 다른 것을 구현하더라도 클라이언트가 수정없이 계속 일할 수 있다는 것입니다.
답변
나는 항상 옵션 1의 스타일을 사용했다. 캐싱은 필자의 경우 데이터가 자주 바뀌기 때문에 문제가되지 않았다. 페이지 크기를 구성 할 수 있으면 데이터를 다시 캐시 할 수 없습니다.
기억하기 어렵거나 부정한 URL을 찾지 못했습니다. 나에게 이것은 쿼리 매개 변수를 잘 사용합니다. 리소스는 분명히 제품 목록이며 쿼리 매개 변수는 목록을 표시하는 방법-정렬 및 페이지를 알려줍니다.
답변
옵션 3에 특정 순서로 매개 변수가 있다고 아무도 지적하지 않았습니다.
http // application / products / 날짜 / 내림차순 / 이름 / 오름차순 / 페이지 / 2
및
http // application / products / 이름 / 오름차순 / 날짜 / 내림차순 / 페이지 / 2
동일한 리소스를 가리 키지 만 URL이 완전히 다릅니다.
나를 위해 옵션 1은 “내가 원하는 것” 과 ” 내가 원하는 것”을 명확하게 분리하기 때문에 가장 수용 가능한 것 같습니다 (물론 롤 사이에 물음표가 있습니다). 전체 페이지 캐싱은 전체 URL을 사용하여 구현할 수 있습니다 (어쨌든 모든 옵션에서 동일한 문제가 발생 함).
URL에서 매개 변수 접근 방식을 사용하면 유일한 장점은 깨끗한 URL입니다. 매개 변수를 인코딩하고 손실없이 디코딩하는 방법을 찾아야합니다. 물론 URLencode / decode로 갈 수는 있지만 URL을 다시 못생긴 것입니다 🙂
답변
쿼리 매개 변수 오프셋 및 제한을 사용하고 싶습니다.
오프셋 : 컬렉션의 항목 인덱스
한도 : 품목 수.
클라이언트는 다음과 같이 오프셋을 계속 업데이트 할 수 있습니다.
offset = offset + limit
다음 페이지를 위해.
경로는 리소스 식별자로 간주됩니다. 그리고 페이지는 리소스가 아니라 리소스 모음의 하위 집합입니다. 페이지 매김은 일반적으로 GET 요청이므로 쿼리 매개 변수는 헤더가 아니라 페이지 매김에 가장 적합합니다.
참조 : https://metamug.com/article/rest-api-developers-dilemma.html#Requesting-the-next-page
