JSON API에서 HTML을 반환해도 괜찮습니까?

현재 프로젝트에서 JSON을 지원하는 것으로 문서화 된 새로 생성 된 RESTful API의 소비와 관련된 서비스 구현을 책임지고 있습니다.

클라이언트는 'application / json'의 승인 헤더와 'application / json'의 컨텐츠 유형을 사용하여 지속적으로 요청합니다. 그러나 일부 엔드 포인트는 컨텐츠 유형의 HTML, 심지어 HTML 본문으로 응답을 보냅니다. 나에게 이것은 분명히 잘못된 접근법이며 결코 정당화 될 수 없습니다.

프로젝트 전반에 걸쳐 동일한 방법이 두 개의 다른 공급 업체와 두 개의 다른 서비스에 적용되었습니다. 서비스를 변경해야하는 이유를 정당화해야한다는 것을 알았습니다. 벤더들은 클라이언트가 이것에 대처해야한다고 말했고 기본 REST 라이브러리는 기본적으로 'out the box'에 대응하지 않기 때문에 (RestEasy) 질문되었습니다 (RestEasy).

이것은 좌절의 주요 포인트였습니다. 나는 나의 주장을 뒷받침하는 많은 참고 문헌을 찾을 수 없다. 나는 그것이 명백한 것처럼 요점이 약하기 때문이라고 생각한다.

문제는 뭔가 빠졌습니까? 내가 이것에 대해 현혹되고 있습니까? 이 시나리오에서 컨텐츠 유형의 application / json이없는 JSON API를 사용하는 것이 좋습니까? 참고로 감사하겠습니다. 상업적 관점에서이 상황을 어떻게 해결합니까?

accept특정 미디어 유형을 요청 하는 헤더를 보낼 때 서버는 다른 것을 다시 보내면 안되며, 200 OK 상태 코드를 사용하지 않아야합니다.

Restpatterns.org에서 :

수락 헤더 필드가 없으면 클라이언트가 모든 미디어 유형을 승인하는 것으로 가정합니다. 수락 헤더 필드가 있고 서버가 결합 된 수락 필드 값에 따라 허용되는 응답을 보낼 수없는 경우 서버는 406 (허용되지 않음) 응답을 보내야합니다.

(엠파 시스 마인)

Restpatterns.org는 이것을 실제 HTTP 표준에서 가져 왔습니다 : 헤더 필드 정의-수락

한마디로 : 당신은 pedantic되지 않습니다. accept 헤더가 구체적으로 리턴하도록 지시 할 때 HTML을 리턴하는 경우 서비스는 HTTP 표준을 따르지 않습니다 application/json.

"RESTful JSON API"의 의미-여기서 첫 번째 문제는 개념을 혼동하고 있다는 것입니다 (또는 "공급자"의 기술 담당자 사이에있는 누군가).

RESTful API (실제로 1 단계에서 휴식을 취하 든 3 단계 이상에서 대화하지 않든 cf http://martinfowler.com/articles/richardsonMaturityModel.html )은 API와 상호 작용하지 않는 방식에 관한 것입니다. 주고받는 컨텐츠의 형식 프로토콜이나 전송 메커니즘조차도 아닙니다 ...

마찬가지로 JSON API는 JSON을 데이터 형식으로 사용하는 것을 지원하는 API입니다. 편안하지 않을 수도 있고, HTTP를 사용하여 구현되거나 구현되지 않을 수도 있으며, 이것이 JSON을 지원 하거나 지원 하지 않을 수도 있습니다. 독점적으로.

HTTP를 통해 실행 되는 좋은 API (HTTP를 통해 노출 된 API에 대해 이야기하고 있다고 가정하는 것이 합리적 임)를 사용하면 다양한 형식의 콘텐츠를 요청할 수 있으며 이러한 형식은 HTML과 JSON과 XML. 왜? 글쎄, 그것은 API를 훨씬 쉽게 배우게 할 것입니다. 개념적으로 어떤 목적이든간에 인스턴트 브라우저 기반 UX를 제공합니다 ...

흥미로운 질문은 다양한 컨텐츠 형식을 지원하는 API가 클라이언트가 어떤 형식을 기대하는지 알려주지 않고 호출되면 어떤 형식을 반환해야 하는가입니다. 이것은 종교적인 주장으로 향하는 경향이 있지만 HTML은 제공자에게 유용한 정보를 포함 할 수있는 옵션을 제공합니다 (예 : "컨텐츠 수락 헤더를 설정해야 함").

API에 대한 질문에 대답하기 위해, 편안하고 json을 지원하는 API는 요청 된 콘텐츠 인 경우 HTML을 절대 반환 할 수 있어야합니다.

클라이언트는 'application / json'의 승인 헤더와 'application / json'의 컨텐츠 유형으로 지속적으로 요청합니다.

예, 이것이 올바른 일이지만 벤더가 관심을 갖는 것은 아닙니다. 나는 좌절감을 완전히 이해하고 있지만 JSON 서비스는 항상 JSON 응답을 제공해야하지만 그렇지 않은 많은 예가 있다고 생각하기 때문에.

프로젝트 전반에 걸쳐 동일한 방법이 두 개의 다른 공급 업체와 두 개의 다른 서비스에 적용되었습니다. 서비스를 변경해야하는 이유를 정당화해야한다는 것을 알았습니다. 벤더들은 클라이언트가 이것에 대처해야한다고 말했고 기본 REST 라이브러리는 기본적으로 'out the box'에 대응하지 않기 때문에 (RestEasy) 질문되었습니다 (RestEasy).

글쎄, 나는 공급 업체에 동의해야한다. 그것은 그들의 서비스이며 그것을 사용하기위한 특별한 경우를 명확하게 문서화하는 한 실제로 그것을 변경하도록 강요 할 수는 없습니다. 개발자가 자신의 API를 채택하는 데 시간이 오래 걸리고 개발자가 필요로하는 것을 들으면 API를 변경하더라도 표준을 따라야한다는 규칙은 없습니다.

문제는 뭔가 빠졌습니까?

요청 헤더는 다른 쪽 끝에서 올바르게 중단되지 않는 한 아무 의미도 없습니다. PHP를 사용하여 웹 API를 개발하면 요청 헤더를 사용하지 않아도됩니다. 내가 원하는대로 응답 할 수 있습니다. 반면 C #으로 IIS에 구성된 서비스는 요청 헤더, 유형 및 응답 유형을 훨씬 쉽게 처리 할 수 ​​있습니다. 벤더가 API를 빌드하는 데 사용한 도구와 관련이 있습니다.

나는 이것에 대해 현혹되고 있습니까?

예, 아니오. 과거를 지나칠 수없는 개발자 친구가 있습니다. API는 문제로 인해 고쳐지고 API가 작동 할 것으로 예상 될 때까지 다른 작업을 진행할 수 없습니다. 이제는 농담입니다.

공급 업체가 작업을 완료하기 위해 "추가 작업"을 작성했기 때문에 문제가됩니다. 그것에 의해 누구나 좌절 할 것입니다. 내가 될 줄 알아

이 시나리오에서 컨텐츠 유형의 application / json이없는 JSON API를 사용하는 것이 좋습니까?

물론 좋은 습관은 아닙니다.

클라이언트는 컨텍스트 유형이 무엇인지 서버에 알려줄 수 있습니다 request. 에 콘텐츠 유형을 적용 할 수있는 기능이 없습니다 response. 클라이언트는 accept가능한 컨텐츠 유형의 모음을 서버에 알릴 수만 있습니다.

헤더 필드 정의

요청 헤더 승인 필드를 사용하여 응답에 적합한 특정 매체 유형을 지정할 수 있습니다. 수락 헤더는 요청이 인라인 이미지에 대한 요청의 경우와 같이 소량의 원하는 유형으로 특별히 제한됨을 나타내는 데 사용될 수 있습니다.

클라이언트가의 이미지를 요청할 수는 image/jpeg있지만 서버 가 이미지를 찾지 못한 경우의 응답 text/html및 상태 코드로 이미지를 요청할 404수 있습니다. 서버가 잘못 응답 할 수도 있습니다. 찾을 수없는 파일에 대한 응답 text/html및 상태 코드 가있는 Wordpress 웹 사이트가 많이 있습니다 200.

이제는 서버 측의 모든 나쁜 연습입니다. 내가 당신에게 말하려고하는 것은 그것이 절대적으로 가능하고 자주 발생한다는 것입니다. 사람들은 이러한 것들을 구성 할 때 무엇을하고 있는지 모릅니다.

참고로 감사하겠습니다. 상업적 관점에서이 상황을 어떻게 해결합니까?

나는 몇 가지 프로젝트 에서이 문제에 부딪쳤다. 당신은 post서버에 JSON 데이터와이 중 하나 JSON 또는 HTML 응답을 다시 제공합니다.

응답에 어떤 유형이 있는지 아는 것은 그리 중요하지 않습니다. 첫 번째 문자 {이거나 [JSON 인 경우 그렇다면 <HTML이라고 가정 할 수 있습니다. 그것이 내가 과거에 처리 한 방법입니다. 때때로 API를 작성한 프로그래머는 HTTP 헤더에 대해 jack을 모두 알고 있습니다. 모든 것이 text/html응답으로 돌아옵니다 . 운이 좋으면 Apache가 기본값으로 구성되어 text/plain때로는 도움이 될 수 있습니다.

이러한 문제는 존재하며 앞으로도 계속 존재할 것입니다. 서버 간 통신은 지금까지 규제되지 않은 활동입니다. 잘못된 HTTP 응답을 제공하는 서버에 대한 노조에서 벤더를 쫓아내는 통치 기관은 없습니다.