내 응답에 대해 application/octet-stream을 반환하여 REST 성경의 법칙을 위반 했습니까? REST 엔드 포인트는 5 개의 이미지 URL을받습니다.REST 인터페이스에서 application/octet-stream을 반환해도 괜찮습니까?
{ "image1": "http://ww.o.com/1.gif",
"image2": "http://www.foo.be/2.gif" }
그리고 이것들을 다운로드하고 응용 프로그램/octet-stream을로 돌아갑니다.
CLARIFICATION :이 REST 인터페이스를 호출하는 클라이언트는 모바일 앱입니다. 추가로 네트워크를 연결하면 배터리 수명이 몇 밀리 암페어 감소합니다. REST는 회사 표준이기 때문에 강제로 사용해야합니다. 그렇지 않다면, 나는 내 자신의 바이너리 프로토콜을 할 것이다.
클라이언트는 이러한 바이너리 데이터를 어딘가에 저장하거나 다른 프로세스로 보내지 않는 경우를 제외하고는 (클라이언트가 데이터로 처리해야하는 경우) 그렇다면 괜찮습니다).
multipart 콘텐츠 유형을 살펴볼 수 있습니다. 여러 개의 image/gif 부분을 포함하는 다중 부분 메시지 인 IMO가 더 나은 대안입니다.
왜 5 번의 별도 REST 호출이 필요하지 않습니까?
더 깨끗하게 보이고 더 논리적으로 나눕니다. 또한 사용중인 브라우저에 따라 한 번에 2 개 이상 다운로드가 동시에 실행됩니다.
어쩌면 정말로'n' URL이 있고 모든 단일 이미지에 대해 HTTP req/resp를 사용하여 반복하는 것은 값 비쌉니다. 요청 당 실제로 링크가 여러 개있는 경우 단일 이미지를 제공하면 더 간단하게 만들 수 있습니다. –
n 값이 매우 큰 경우를 제외하고는 모두 함께 포장하면 RESTful하지 않습니다. n이 매우 큰 경우 다른 전략이 더 적합 할 수 있습니다. –
클라이언트는 브라우저가 아닌 기본 모바일 앱입니다. –
이 소리는 RPC 호출과 비슷합니다. 구체적으로 말하자면, "여기에 URL 목록이있어서 저에게 아카이브를 보내주십시오".
REST는 RPC 기반 시스템이 아니기 때문에이 프로세스는 특히 RESTful이 아닙니다.
당신이해야 할 일은 아카이브를 재원으로 취급하고 그것을 만들고 나서 제공하는 것입니다.
당신이 할 수 예를 들어 결과
POST /archives
Content-Type: application/json
{ "image1": "http://ww.o.com/1.gif",
"image2": "http://www.foo.be/2.gif" }
, 당신이 그런
HTTP/1.1 201 Created
Location: http://example.com/archives/1234
Content-Type: application/json
을 얻을 것입니다, 당신은 http://example.com에 요청을 만들 수 :
GET /archives/1234
Accept: multipart/mixed
를 여기에서 원하는대로 단일 요청으로 실제 아카이브를 가져오고, 다중 파트 형식의 결과 만 제공합니다. 당신이 한 경우
(다중 /의 X-우편은 그 zip 파일입니다, 너무 일 것이다) :
GET /archives/1234
Accept: application/json
당신은 당신이 (그래서 당신은 아마도, 수 원래 보낸 JSON, 편집을 다시 얻고 업데이트 할 것 아카이브, 바이너리 이미지 전송 지원을 원하지 않는 경우).
PUT /archives/1234
Content-Type: application/json
{ "image1": "http://ww.o.com/1.gif",
"image2": "http://www.foo.be/2.gif",
"image3": "http://www.foo2.foo/4.gif" }
자원은/아카이브/1234, 그 이름의 :
는 단순히 업데이트를 다시 POST 것을 변경합니다.JSON 버전과 실제 이진 보관 파일은이 경우 두 가지 표현이 있습니다.서비스는 수락 헤더에 지정된 콘텐츠 형식을 사용하여 두 서비스를 구별합니다. 그 헤더는 고객이 원하는 것을 말하고 있습니다.
당신이 아카이브를 완료하면, 단순히
DELETE /archives/1234
또는 서버를 가질 수 있습니다 삭제 좀 나중에 자원을 만료됩니다.
'PUT'과'POST'를 혼동하지 않았습니까? 'PUT'은 보통'/ archives/1234'와 같은 리소스를 업데이트하기위한 것이고'POST'는 여러분의 예제에서 새로운 아카이브와 같은 새로운 것들을 생성하기위한 것입니다 :'POST/archives'. –
네가 맞아, 지금 바꿔 놨어. –
이들은 법률이 아닌 REST 원칙이라고 부르지 만 IMO를 "위반하지"는 것은 아닙니다. REST는 URL로 주소 지정할 수있는 자원에 관한 것이며, 적절한 경우 여러 형식으로 사용할 수 있습니다. 형식이 무엇인지는 말하지 않습니다. REST가 의미하는 것의 간단한 설명이 in this article입니다.
그러나 @Andrey는 자신의 애드혹 형식을 고안하는 것보다 여러 데이터 객체를 보내는 것을 다루는 더 좋은 방법이 있다고 말합니다. Multipart mimeType/형식은 하나의 대안이며 다른 하나는 tar, zip 또는 유사한 아카이브 파일 형식으로 압축 된 개체를 보내는 것입니다.
IMO. "application/octet-stream"을 사용할 때의 실질적인 문제는 데이터가 실제로 어떻게 포맷되는지 아무에게도 알려주지 않는다는 것입니다. 오히려 클라이언트는 형식화 방법을 "알"있으며 그에 따라 해석합니다. 그리고 독자적인 형식을 고안하는 데 따르는 문제는 상호 운용성과 (가능하다면) 지원할 라이브러리를 설계, 구현 및 유지 관리해야 할 가능성이 있습니다.
언급 한 것처럼 문제는 페이로드가 아니며 콘텐츠 유형입니다. 이상적으로, 컨텐트 유형은 가능한 한 데이터를 설명합니다. Multipart가 훨씬 적합합니다. 또한 이미지를 혼합 할 수 있습니다 (예 : PNG와 JPG 결합). 비용은 새 메타 데이터에 대한 최소 오버 헤드입니다. –