2012-02-14 2 views
0

JSON을 사용하는 경우 JSON을 반환합니다. XML을 사용하는 경우 XML을 반환합니다. 양식으로 인코딩 된 데이터를 허용하는 요청 ("application/x-www-form-urlencoded")에 대해 양식 인코딩 데이터를 반환하는 것이 허용 될 수 있습니까?REST 서비스가 입력 내용 유형을 사용하여 응답해야합니까?

또한 오류가 발생한 경우 대부분의 구현은 어떤 작업을 수행합니까? 주제가 매우 다양합니다.

답변

2

끔찍한 접근 방식은 아니지만 양식 인코딩 된 데이터를 반환하는 것은 내가 본 적이없는 것입니다. 가장 보편적 인 형식을 유지하는 것이 가장 좋습니다. 대부분의 API는 요청에 의해 지정된 것이 없을 때 보낼 기본 형식 (보통 XML 또는 JSON)을 선택합니다.

오류의 경우 REST의 기본 원칙은 HTTP가 이미 제공하는 방법을 사용하기 때문에 먼저 응답 본문에 오류 메시지와 함께 적절한 오류 상태 코드 (400s and 500s)를 반환합니다. Flickr 년대처럼

{ "error" : "Invalid articled ID" } 

.. 또는 더 복잡 :

오류의 몸에 대한 표준 포맷 없습니다 응답은-는 것처럼 간단 할 수

{ "stat" : "fail", 
    "code" : "97", 
    "message" : "Missing signature" 
} 

. . 및 해당 XML 등가 :

<?xml version="1.0" encoding="utf-8" ?> 
<rsp stat="fail"> 
    <err code="97" msg="Missing signature" /> 
</rsp> 

분명히 API를 사용하는 개발자는 더 자세한 오류 메시지를 이해할 수 있습니다. 주로 Message이라는 매개 변수가있는 경우 한 곳에서 message이라는 매개 변수가없는 경우 API에서 일관성을 찾아야한다고 생각합니다.

제쳐두고로서

는 I 위 과실으나 관 (|)와 같은 결과를 리턴 XML로 묶어 데이터를 분리뿐만 아니라 실제로 타사 제조 API 처리했다. 값의 리터럴 파이프가 다른 파이프 (||)로 이스케이프되었습니다. 우리가 발견 한 그 이상의 합병증은 당신의 상상력으로 남겨 둘 것입니다. 도덕적 인 이유는 개발자가 이미 익숙한 구조와 기법을 사용하는 것인데, 이상의 내용이 일관성을 유지하기 위해서는을 선택하는 것이 좋습니다.

+0

차갑다. 양식으로 인코딩 된 데이터를 다시 보내는 것은 잘못되었으므로 문제가됩니다. 설명을 위해 : 요청에서 양식 인코딩 된 데이터를 지원하는 경우 JSON 또는 XML을 응답으로 반환하는 것이 합리적입니까? –

+0

그것이 문서화되어있는 한 그것이 나에게 의미가 있습니다. –

+0

나에게 좋은 소리! JSON을 기반으로 구축하고 싶지만 레거시 호출자는 여전히 양식으로 인코딩 된 POST를 지원해야합니다. 이러한 조언을 통해 우리는 필요를 충족시킬 수 있습니다. 고맙습니다! –

3

아니요. 이유가 없습니다.

그러나 클라이언트 은 Accept : 헤더로 특정 형식을 요청할 수 있습니다. 서버가 형식을 지원하지 않으면 406 Not Acceptable을 반환해야합니다. Accept : 헤더가 전혀 없거나 클라이언트가 *를 폴백으로 사용하는 경우 서버는 기본값을 선택할 수 있습니다.

관련 문제