2015-01-29 2 views
0

내 호출 중 하나가 /api/1/orders/1234 인 REST API를 개발 중입니다. 결과는 기본적으로 Json 형식으로 반환되고 AngularJS의 도움을 받아 브라우저 창에 표시됩니다.REST 및 PDF 보고서

이 특별한 경우에는 인쇄, 서명 (손으로) 및 법적 목적으로 저장되는 PDF 버전의 리소스를 생성해야합니다. 이 호출에는 보고서를 생성하는 데 필요한 모든 데이터가 포함되어 있으므로이 작업을 수행하는 데 권장되는 방법은 무엇입니까?

내 생각에, PDF 버전은 단순히 리소스의 다른 형식이며 쿼리 매개 변수 (?format=pdf)를 추가하는 것만으로도 충분하지 않을 수 있습니다. 더 나은 방법이 있습니까 (특히 서버 측을 구현하기가 더 어렵거나 쉽지는 않을 것입니다).

어디서나 이렇게하는 권장 방법을 찾을 수 없으므로 어떤 힌트라도 좋을 것입니다. 죄송합니다.이 질문이 "의견을 바탕으로 한 질문"이 너무 많습니다.

+0

content-type : application/pdf –

+0

@WonTonSoup 아니요, Content-Type은 요청/응답 본문의 MIME을 지정합니다. 어쩌면 당신이'Accept'를 의미했을 수도 있지만, 문제는 일부 클라이언트가 커스텀'Accept' 필드를 지원하지 않는다는 것입니다. –

답변

1

올바른 방법은 내용 협상을 허용하는 요청 헤더 필드를 사용하는 것입니다. 솔루션 api/1/orders/1234.pdf

당신이 클라이언트를 제어 할 수 있습니다 또는하지 않을 경우 (나뿐만 아니라 내 펄 CLI 클라이언트를 쓰기), 따라 약간의 청소기가 있지만

api/1/orders/1234?format=pdf 귀하의 제안 일할 수

, 나는에 대해 방해되지 않을 것이다 전체 HTTP 사양을 지원하지 않는 브라우저 우리가 허위의 고객을 지원할 의무가 있다고 느끼면, 그 고객을 업그레이드 할 충동은 없을 것입니다.

1

이러한 상황을 처리하는 데 권장되는 방법은 content negotiation입니다.

응답이 페이로드 정보를 전달할 때 원 서버는 종종 다른 정보 표현 방법을 사용합니다. 예 : 다른 형식. 이러한 이유로 HTTP는 콘텐츠 협상을위한 메커니즘을 제공합니다.

Apache HTTPD content negotiation documentation은 좋은 예제를 제공합니다 (httpd를 사용하지 않는 경우 구성 세부 사항을 무시할 수 있음). 응용 프로그램 클라이언트에서 API를 사용하면 잘 작동합니다.

그래서 클라이언트가 JSON 표현을하고자 할 때, 그것은

GET /api/1/orders/1234 HTTP/1.1 
Host: example.org 
Accept: application/json 

를 요청할 수 있으며, 클라이언트가 PDF 표현을하고자 할 때, 그것은

GET /api/1/orders/1234 HTTP/1.1 
Host: example.org 
Accept: application/pdf 

그러나, 상황이 조금 변경 요청할 수 있습니다 클라이언트가 주소 표시 줄에 URL을 입력 할 때 일반적으로 일반 Accept 헤더를 보내기 때문에 클라이언트는 기본적으로 브라우저입니다. Firefox, Safari, Chrome, Internet Explorer 및 Opera here과 같은 일반 브라우저의 값을 확인할 수 있습니다.

예를 들어 Chrome은 다음 Accept 헤더를 보냅니다.

Accept: application/xml,application/xhtml+xml,text/html;q=0.9, text/plain;q=0.8,image/png,*/*;q=0.5 

그래서이 경우, 어떤 브라우저가 말하고있는 것은 XML과 HTML, 그렇지 않은 경우 일반 텍스트, PNG 이미지 또는 어떤 다른 유형을 선호한다는 것이다. 이 경우 json이나 pdf (사용자가 브라우저를 사용하여 쉽게 지정할 수 없음)에 대한 선호도를 알려주지 않습니다.이 경우/api/1/orders/1234 (또는 /api/1/orders/1234.json) 및 /api/1/orders/1234.pdf와 같은 두 개의 URL을 갖는 것이 합리적 일 수 있습니다.

따라서 원하는 클라이언트 유형에 따라 선택이 달라집니다. 그러나 동일한 리소스를 두 가지로 표현한 경우 HTTP를 사용하여 콘텐츠를보다 적절하게 교환하는 방법은 콘텐츠 협상을 사용하는 것입니다.

관련 문제