일시적 REST 표현

아이스크림 가게를 모델링하는 RESTful 하이퍼 텍스트 기반 서비스가 있다고 가정 해 보겠습니다. 내 상점을 더 잘 관리 할 수 있도록 판매 된 각 종류의 아이스크림의 일일 보고서 리스팅 수량과 달러 가치를 표시 할 수 있기를 원합니다.일시적 REST 표현

이보고 기능이 DailyReport라는 리소스로 노출 될 수있는 것 같습니다. DailyReport는 신속하게 생성 될 수 있으며 실제로 서버에 보고서를 저장하는 데 이점이없는 것처럼 보입니다. DailyReport를 얻는 것에 신경 쓰지 않는 며칠 동안 DailyReport 만 원한다. 또한 DailyReports를 서버에 저장하면 클라이언트 구현이 복잡해 지므로 더 이상 필요하지 않은 보고서를 삭제해야합니다.

DailyReport는 일시적입니다. 표현은 한 번만 검색 될 수 있습니다. 이를 구현하는 한 가지 방법은 "/ daily-reports"링크를 제공하는 것입니다. POST는 해당 날짜의 판매에 대한 정보가 나열된 DailyReport 표현을 포함하는 응답을 반환합니다.

편집 : 내가 실제로 POST 요청을하고 싶다고도합시다. DailyReport에는 아이스크림 유형을 알파벳순으로, 달러 값으로 - 또는 시간별 분류를 포함하여 또는 옵션으로 해당 날짜의 온도를 포함하여 정렬하거나 특정 아이스크림 유형을 필터링하여 목록으로 만드는 것과 같은 다양한보기 옵션이 있습니다. GET과 함께 쿼리 매개 변수를 사용하는 대신 적절한 옵션 (각 옵션을 문서화하기 위해 잘 정의 된 사용자 지정 미디어 유형 사용)을 사용하여 DailyReport 표현을 게시하고 싶습니다. 내가 돌아 오는 표현은 보고서 자체와 함께 옵션을 표시합니다.

문제를 생각하는 올바른 방법입니까, 아니면 대신 다른 방법을 사용해야합니까? 올바른 경우 DailyReport 자원을 구현할 때 특별한 고려 사항이 중요 할 수 있습니까? 예를 들어, POST 요청 후에 리턴 할 때 Location 헤더를 설정하는 것은 적절하지 않을 수 있습니다.

출처

2009-08-20 Rich Apodaca

일일 보고서를 사용할 수있게하려면 /daily_reports/2009/08/20에 GET으로 구현할 수 있습니다. 나는 John Millikin과 함께 여기서 POST가 불필요하다는 것에 동의합니다. 사용자가 만들 수있는 리소스가 될 필요가 없습니다.

매일 자신의 URI로 사용할 수있는 보고서를 만드는 것이 장점입니다.

편집 :이 좋은 해결책이 daily_report/ 현재 날짜의 데이터의 노 캐시 표현 daily_reports/yyyy/mm/dd 하루 종일 데이터의 캐시 표현을 두 답변을 병합 할 수 있습니다.

출처

2009-08-20 22:10:37

은 최근에'ordinary_report'를 영구 버전으로의 영구적이지 않은 리디렉션으로 만들었습니다. – xenoterracide

보고서를 요청해도 서버 상태가 변경되지 않으므로 POST를 사용할 필요가 없습니다. 당신의 편집에 응답

GET /daily-report/ 

200 OK 
Pragma: no-cache 
<daily-report for="2009-04-20" generated-at="2009-4-20T12:13:14Z"> 
    <!-- contents of the report here --> 
</daily-report>

: 나는이 같은 자원을 사용하면 결과로 설정 임시 데이터를 URL로 보고서의 설명을 게시하고 검색하는 경우, 즉에서 REST 아니에요 모든. SOAP와 동일한 맥락의 RPC입니다. RPC는 본질적으로 나쁜 것은 아니지만 제발, 제발 RESTful 전화하지 마십시오.

출처

2009-08-20 22:08:44

좋은 지적. DailyReport에 적용 할 수있는 여러 매개 변수가있는 경우 (예 : 알파벳순 또는 달러형으로 정렬) - 쿼리 매개 변수를 사용하지 않으려면 어떻게해야합니까? 또는 기간을 지난 24 시간 이외의 다른 기간 (예 :보다 일반적인 목적의 보고서 자원)으로 설정하려면 어떻게해야합니까? 이러한 옵션을 쿼리 매개 변수로 포함하지 않고 POST 페이로드로 보낸 본격적인 표현으로 포함한다고 가정 해 봅시다. 그건 내가 생각하는 것에 더 가깝다. –

왜 쿼리 매개 변수를 사용하지 않으시겠습니까? 그것이 그들이 존재하는 것입니다. 사용자 지정 보고서 범위는 쿼리 매개 변수를 사용하여 제공 될 수도 있습니다. 매개 변수가 너무 복잡하여 쿼리 문자열에 표시 할 수없는 경우 해당 매개 변수를 서버에 업로드하고 일일 보고서를 하위 리소스로 만드는 것이 좋습니다. –

나는 Greg's approach이 맞다고 생각합니다. 설명하면 화요일에 11시 59 분에 보고서를 실행하면 수요일 00:01에 실행하는 것과 다른 결과가 발생하기 때문에 매일 변경되는 /daily-report 리소스를 제공해야한다고 생각하지 않습니다. 이는 다음과 같이 혼동을 일으킬 수 있습니다. 클라이언트는 리소스가 동일 할 것으로 예상하고, B) 클라이언트가 하루가 지나면 이전 날짜의 데이터를 검색하는 것을 허용하지 않습니다.사용할 수있는 일별 보고서마다 고유 한 리소스 식별자를 제공해야합니다. 그러면 클라이언트가 언제든지 필요한 정보에 액세스 할 수 있습니다.

출처

2009-08-20 22:16:48

/TodaysWeather 유형의 리소스를 사용하는 것이 일반적입니다. GET간에 리소스가 변경되면 클라이언트가 놀라지 않아야합니다. –

Darrel의 의견에 동의합니다. 적절한 만료 헤더 만 추가하면됩니다. 검색된 시점까지 현재를 나타내는 자원을 얻는 것은 완전히 유효합니다. API 소비자에게 명확하게 나타내려면 별도의 URI 형식을 사용하는 것이 좋습니다. /daily-report /archive/daily-reports/2009/02/12 REST는 URI 디자인에 신경 쓰지 않지만 유용한 API를 디자인하는 데 중요합니다. –

때로는 보고서 요청 기록을 유지하는 것이 바람직합니다. 이러한 경우 보고서 수집 자원에 게시하는 것이 부당하지 않을 수 있습니다. 또한 실행을 비동기 적으로 처리하려는 장기 실행 보고서에 유용합니다. 서버가 보고서 요청에 얼마나 오랫동안 붙잡 았는지는 귀하에게 달려 있습니다.

나는 옵션을 포함하여 요청의 표현을 반환

POST /DailyReportRequests

그런 짓을하고 할 보고서가 완료되면, 보고서 결과에 대한 링크.

미리 설정된 보고서 세트를 사용할 때 좋은 또 다른 방법은 사전 구성된 보고서 링크 목록이 포함 된 DailyReports 리소스를 만드는 것입니다. OpenSearchDescription 스펙을 사용하면 Query 태그를 사용하여 이와 유사한 작업을 수행 할 수 있습니다.

출처

2009-08-20 23:31:37

답변

관련 문제