Sun Cloud API (http://kenai.com/projects/suncloudapis/pages/Home)는 RESTful API를 따르는 좋은 예입니다. RESTful 원칙에 충실하면서, 리소스를 얻었을 때 그 리소스의 표현보다 많지도 작지도 않습니다.RESTful API를위한 Mimetype
응답의 Content-Type 헤더는 해당 리소스의 유형을 정확히 알려줍니다 (예 : application/vnd.com.sun.cloud.Snapshot + json). Sun은 이러한 mimetype을 IANA에 등록했습니다.
현재 일반적으로 얼마나 실용적입니까? 내가 본 대부분의 API는 "application/json"의 Content-Type을 사용했습니다. 이것은 응답이 JSON이지만 그 이상은 아니라는 것을 알려줍니다. "type"속성과 같이 JSON 개체에 무엇이 있는지 알아야합니다.
저는 공개 API가 설계되지 않았기 때문에 mimetypes를 등록하지 않을 것입니다. 나는 RESTEasy를 사용하고 있는데, 비록 완전한 MIME 타입을 지정했다 할지라도, 응답 헤더의 Content-Type은 정확히 Accept 요청 헤더가 지정한 것이 될 것이다. 요청이 "application/* + json"을 요청하면 기본적으로 응답 헤더에 "application/* + json"이 포함됩니다. 응답을 보내기 전에 헤더를 변경하여이 문제를 해결할 수는 있지만이를 시도해야합니까? 요청에 대한 응답과 마찬가지로 응답에 와일드 카드가 있어야합니까?
아니면 대부분의 API처럼 "application/json"을 제공해야합니까?
추가 생각은 나중에 추가 :
질문을 진술하는 또 다른 방법은 다음과 같습니다 나는 프로토콜로 HTTP를 사용하는 경우, 또는 내가 HTTP 단지 내 자신의 프로토콜을 포장하는 전송 메커니즘으로 사용해야합니까?
HTTP를 프로토콜로 사용하려면 응답의 엔터티 본문에 요청한 개체의 표현 (또는 오류 메시지 개체의 표현)이 들어 있고 "Content-Type"머리글에는 개체의 정확한 유형이 들어 있으며, "Status"헤더에는 성공 또는 오류 코드가 들어 있습니다.
HTTP를 단순히 전송 메커니즘으로 사용하려면 "Status"헤더가 항상 200 OK로 설정되고 "Content-Type"은 "application/json"과 같은 일반 사항이며 엔터티 본문에는 객체, 객체 유형, 오류 코드 등 원하는 것을 선택하십시오. 자신의 프로토콜이 RESTful 인 경우 전체 스키마가 RESTful입니다. (HTTP는 RESTful 프로토콜이지만 가능한 유일한 프로토콜은 아닙니다.)
자신의 프로토콜은 모든 전송 계층에 불투명합니다. HTTP를 프로토콜로 사용하면 모든 전송 계층에서이를 이해하고 원하지 않는 일을 할 수 있습니다. 예를 들어, 브라우저가 "401 Unauthorized"응답을 가로 채고 직접 처리하려는 경우에도 로그인 대화 상자를 표시합니다.
웹 클라이언트에서 가지고있는 한 가지 문제점은 HTTP 상태 코드와 헤더의 브라우저 차단입니다. 예를 들어 401 Unauthorized를 반환하면 브라우저에서 브라우저를 점유하고 자체 로그인 대화 상자를 표시하기 전에 자바 스크립트 클라이언트가이를 확인하지 못합니다. 그 때부터 브라우저는 모든 요청에 대해 자체 Authorization 헤더를 넣습니다. Mimetypes는 OK를 통과하지만 하나 이상의 상태 코드 (401)가 문제입니다. –