[http] 나머지 컬렉션에서의 페이징

JSON 문서 ( CouchDB 또는 Persevere 생각)에 직접 REST 인터페이스를 노출하는 데 관심이 있습니다. 내가 겪고있는 문제 GET는 컬렉션이 큰 경우 컬렉션 루트 에서 작업 을 처리하는 방법 입니다.

예를 들어 척하는 것처럼 Questions각 행이 문서로 노출되는 StackOverflow의 테이블을 노출하고 있습니다 (필요한 테이블이 아니라 크기가 큰 ‘문서’집합의 구체적인 예). 컬렉션에서 사용할 수있게 될 것이다 /db/questions일반적인 CRUD API를 사용하여 GET /db/questions/XXX, PUT /db/questions/XXX, POST /db/questions놀이입니다. 전체 컬렉션을 가져 오는 표준 방법은 GET /db/questions각 행을 순식간에 JSON 객체로 덤프하는 경우 다소 규모가 큰 다운로드가 가능하며 서버 측에서 많은 작업이 수행됩니다.

해결책은 물론 페이징입니다. Dojo는 사용자 정의 범위 단위로 헤더를 사용하는 영리한 RFC2616 호환 확장을 통해 JsonRestStore 에서이 문제점을 해결했습니다 . 결과는 요청 된 범위 만 반환합니다. 쿼리 매개 변수에 비해이 방법의 장점은 쿼리 문자열을 쿼리에 남겨 두는 것입니다 (예 : 또는 예를 들어 , 인코딩 된 예 ).Rangeitems206 Partial ContentGET /db/questions/?score>200%3E

이 접근법은 내가 원하는 행동을 완전히 다룹니다. 문제는 RFC 2616 이 206 응답 (강조 광산)에서 다음을 지정한다는 것입니다.

요청 범위 헤더 필드 (반드시 포함했다 섹션 14.35 ) 원하는 범위를 나타내는, 및 IF-Range 헤더 필드 (포함되어있을 수 부 14.27 요구 조건을하기 참조).

이것은 헤더의 표준 사용법과 관련이 있지만 206 응답이 순진한 클라이언트 / 무작위 사람들이 탐색하는 기본값을 원하기 때문에 문제가됩니다.

솔루션을 찾기 위해 RFC를 자세히 살펴 보았지만 솔루션에 만족하지 않아서 SO가 문제를 해결하는 데 관심이 있습니다.

내가 가진 아이디어 :

• 돌아 200와 Content-Range헤더! -나는 이것이 틀렸다고 생각하지 않지만 응답이 부분 내용 일뿐이라는 더 명확한 지표를 선호합니다.
• 반환400 Range Required -필요한 헤더에 대한 특수 400 응답 코드가 없으므로 기본 오류를 직접 읽고 읽어야합니다. 또한 웹 브라우저 (또는 Resty와 같은 다른 클라이언트)를 통한 탐색이 더 어려워집니다.
• 쿼리 매개 변수를 사용하십시오 -표준 접근 방식이지만 쿼리를 일시적으로 허용하기를 희망하며 쿼리 네임 스페이스가 줄어 듭니다.
• 그냥 돌아와 206! -대부분의 고객은 놀라지 않을 것이라고 생각하지만 RFC에서 반드시 필히 반대하지는 않습니다.
• 사양을 확장하십시오! 반환266 Partial Content -206과 똑같이 동작하지만 Range헤더를 포함해서는 안되는 요청에 대한 응답 입니다. 나는 266이 충돌 문제에 부딪치지 않을 정도로 충분히 높으며 나에게 의미가 있지만 이것이 금기 사항인지 아닌지는 확실하지 않습니다.

나는 이것이 상당히 일반적인 문제라고 생각하고 나는 이것이 일종의 사실상의 방식으로 이루어지기를 원하기 때문에 나 또는 다른 사람이 바퀴를 재발 명하지 않습니다.

컬렉션이 클 때 HTTP를 통해 전체 컬렉션을 노출하는 가장 좋은 방법은 무엇입니까?

답변

Link: <>; rel="http://paged.collection.example/relation/paged"
Link: <>; rel="http://paged.collection.example/relation/paged"
...

GET /db/questions HTTP/1.1
Host: paged.collection.example
Accept: application/json;PagingSpec=1.0;page=1