콘텐츠 유형 헤더를 수정하면 API를 실행하면 고객에게 문제가 발생합니까?

우리는 API를 사용하는 소수의 사람들과 API를 실행하고 있습니다. 때문에 나의 부분에 일부 기존의 어색함에, 엔드 포인트 중 하나가 반환 잘못된 내용 유형 헤더 , js그것이 있어야 할 때 json. 내 질문은 올바른 값을 반환하기 위해 스와핑 하여이 문제를 해결하면 기존 고객의 문제를 얼마나 심하게 망칠 수 있습니까? 또는 다른 말로하면, 많은 다른 HTTP 클라이언트 라이브러리가 그러한 변화를 볼 때 치명적인 오류가 발생할 것으로 예상합니까?

우리는 이것이 너무 땀을 흘리지 않고 계속 진행할 수있는 변화인지를 결정하려고 노력하고 있거나 모든 사용자에게 신중하게 이메일을 보내고 다년간의 지원 중단 기간을 발표해야합니다.

사용중인 다른 HTTP 클라이언트의 종류에 따라 약간 씩 달라질 수 있으므로 사용자 에이전트를 살펴 보았습니다. 답 : 많은 다른 것들! 다음은 최고의 것들입니다.

"okhttp / 3.2.0", "python-requests / 2.10.0", "Ruby", "python-requests / 2.7.0", "Mozilla / 5.0", "Java / 1.8.0_91", "python-requests /2.4.3 ","okhttp / 3.3.0 ","Lucee ","Dalvik / 2.1.0 ","Google-HTTP-Java-Client / 1.21.0 ","PHP_appname ","NativeHost ","Java /1.7.0_67 ","Apache-HttpClient / UNAVAILABLE ","Dalvik / 1.6.0 ","Web-sniffer / 1.1.0 ","unirest-objc / 1.1 "

다양한 모바일 및 서버 측 언어 라이브러리 대부분 자바 스크립트를 실행하는 브라우저는 아니지만 일부 브라우저도 실행됩니다.

대부분의 사람들은 컨텐츠 유형이 잘못되었음을 알지 못하는 것 같지만,이 문제에 대해 불평하는 새로운 지원 요청이 나오면이를 해결하고자합니다.

기존 고객의 업무를 얼마나 망칠 수 있습니까?

이 콘텐츠 유형 에 의존하는 코드를 잘못 작성하면 전함을 완전히 흡수 할 수 있습니다.

라이브러리에서 오류가 발생하지는 않지만 일부 경우 엄격한 라이브러리가 잘못된 MIME 유형을 처리하기 위해 동작이 재정의 된 것으로 예상합니다.

API가 요청 필드 어딘가에 버전 / 수정 값을 갖는 경우이를 높이고 새 버전에서는 올바른 유형을 리턴하지만 이전 버전에서는 계속 잘못된 유형을 리턴합니다. 그러한 요청 필드가 없다면, 지금 추가해야합니다.

그러한 변화를 볼 때 많은 다른 HTTP 클라이언트 라이브러리에서 치명적인 오류가 발생할 것으로 예상하십니까?

아니요. 프로그래머가 특별히 해당 헤더를 읽고 무언가를 수행하지 않는 한 익숙한 모든 HTTP 클라이언트 라이브러리는 컨텐츠 유형 헤더를 무시합니다. content-type : application / json이 자동으로 json 파서가 관여하는 라이브러리를 상상할 수 있지만 실제로 발생하는 경우는 모르겠습니다.

대부분의 사람들은 컨텐츠 유형이 잘못되었음을 알지 못하는 것 같지만,이 문제에 대해 불평하는 새로운 지원 요청이 나오면이를 해결하고자합니다.

그들은 잘못된 헤더를 어떻게 알았습니까? 잘못된 헤더가 실제로 문제를 일으킨다면 분명히 무시하는 것이 아니라 고쳐지면 문제가있을 수 있기 때문에 그것을 볼 가치가 있습니다.

모든 고객으로부터 사인 오프하지 않고 말하기가 너무 어렵습니다. API를 v.Next로 업그레이드하려면 다음 두 가지 방법 중 하나를 사용하는 것이 좋습니다.

1. 기존 API를 확장하십시오. v.Next 사용을 나타내는 쿼리 문자열 또는 다른 변수를 API에 추가하십시오. 해당 변수를 사용하는 모든 요청에 ​​대해 업데이트 된 컨텐츠 유형을 사용하십시오.
2. 현재 API와 동시에 API의 스테이징 또는 사전 프로덕션 인스턴스를 실행하십시오. 프로덕션과 거의 동일해야합니다. 같은 백엔드를 사용하더라도. 이것은 v.Next에 대한 제안 된 변경 사항을 갖지만.

두 시나리오 중 하나에서 변경 내용과 대상 컷 오버 날짜 / 시간을 고객에게 알리십시오. 서비스 중단이 없는지 확인하기 위해 대상 날짜 전에 테스트를 잘 수행하도록 권장하십시오.

v.Next의 변경 사항을 자세히 설명하는 전용 페이지가 있는지 확인하십시오. 이것은 고객에게 발송 된 커뮤니케이션에 포함되어야합니다. 기존 클라이언트의 수정 사항에 대해 논의한 경우이 페이지의 수정 사항을 포함하십시오.

마지막으로 고객과의 과도한 의사 소통과 스팸 메일의 경계를 밟습니다. 보다 즉각적이고 긴급한 우선 순위가 올라감에 따라 이러한 알림을 쉽게 간과 할 수 있습니다.

FWIW, 일이 현재 작동한다면 나는 그것에 대해 너무 걱정하지 않을 것입니다. 예를 들어, 이것이 심각한 보안 취약점을 일으키는 것을 발견하면이 변경 사항을 적용 할 수있는 좋은 이유입니다. 그렇지 않으면이 변경 사항을 포함하기 위해 더 압박적인 것을 기다릴 것입니다.

이것이 깨질 라이브러리 (예, 단일 명령)의 예는 다음과 같습니다.

파워 쉘의 cmdlet은 Invoke-RestMethodJSON과 다르게 행동한다. 요청의 결과가 JSON, XML 또는 ATOM / RSS 인 경우 (그리고 헤더를 기반으로 생각하는 경우) 구문 분석 / 역 직렬화하고 원시 객체를 리턴합니다. 그렇지 않으면 원시 데이터를 리턴합니다.

따라서 기존 코드는 문자열을 처리하도록 작성되어 (아마도 문자열을 전달하여 ConvertFrom-Json) 갑자기 시작되지 않습니다.

두 가지 결과가 나타났습니다.

1. 일부 클라이언트 라이브러리는 응답을 올바르게 처리하지 않습니다. 예를 들어 응답은 json 또는 배열 대신 문자열을 반환합니다.
2. 압축이 항상 적용되는 것은 아닙니다.