사용되지 않는 API를 클라이언트에 알리기위한 HTTP 응답 헤더에 대한 규칙


84

REST API 엔드 포인트를 업그레이드 중이며 더 이상 사용되지 않는 엔드 포인트를 호출 할 때 클라이언트에게 알리고 싶습니다.
"이 API 버전은 더 이상 사용되지 않습니다. 최신 문서를 참조하여 엔드 포인트를 업데이트하십시오."라는 메시지와 함께 응답에 어떤 헤더를 사용해야합니까?

답변:


72

이전 버전과 호환되도록 상태 코드에서 아무것도 변경하지 않을 것입니다. 응답에 "Warning"헤더를 추가합니다.

Warning: 299 - "Deprecated API"

경고를 내보내는 "Agent"와 함께 "-"를 지정하고 경고 텍스트에서 더 명시 적으로 지정할 수도 있습니다.

Warning: 299 api.blazingFrog.com "Deprecated API: use betterapi.blazingFrog.com instead. Old API maintained until 2015-06-02"

경고 헤더는 https://tools.ietf.org/html/rfc7234#section-5.5에 지정됩니다 . 경고 코드 299는 일반적이며 "사용되지 않음"은 표준이 아닙니다.

API 클라이언트에 HTTP 경고를 기록하고 모니터링하도록 지시해야합니다.

지금까지 사용 해본 적이 없지만 회사가 Rest API에서 더 성숙 해지면 통합 할 것입니다.

편집 (2019-04-25) : @Harry Wood가 언급했듯이 경고 헤더는 설명서의 캐싱과 관련된 장에 있습니다. 그러나 RFC는 명확합니다.Warnings can be used for other purposes, both cache-related and otherwise.

대체 방법을 선호하는 경우이 초안 https://tools.ietf.org/html/draft-dalal-deprecation-header-00 은 새 헤더 "Deprecation"을 제안합니다.


1
경고 값 끝에있는 경고 날짜는 여기서 아무런 의미가 없으며 생략하는 것이 가장 좋습니다. 그렇지 않으면 클라이언트를 혼란스럽게 할 위험이 있습니다. . . Date동일한 메시지 의 값과 다른 경고 날짜를 수신 하면 수신자는 경고 값을 제외해야합니다. . . 전에. . . 메시지를 사용합니다.”
Vasiliy Faronov

경고 날짜를 포함하는 경우 Date헤더 와 동일한 방식으로 형식을 지정해야합니다 "Thu, 02 Apr 2015 12:25:32 GMT"..
Vasiliy Faronov

@VasiliyFaronov :이 경우 (사용되지 않는 API)이 경고 메시지는 항상 미래에 사실이기 때문에 맞습니다. 따라서 응답 (경고 메시지 포함)이 프록시의 캐시에 의해 전송되고 메시지 날짜가 다른 경우 경고는 무시되지만 여전히 유효합니다. 나는 응답 편집
BenC

"경고"헤더가 캐싱과 관련이 있지 않습니까? 문서 링크에서 캐싱에 대해 언급하지만 전체 RFC 문서가 캐싱과 관련된 것 같습니다. 그러나 Warning헤더는 지원 중단을 설명하는 자유 텍스트 위치로 잘 보입니다. DeprecationSunset다른 답변에서 언급 한 헤더는 엄격한 더 잠재적으로 기계 판독 방법으로 사용되지 않음을 설명하기위한 새로운 표준 솔루션이 될 것 같다.
Harry Wood

1
Warning헤더는 캐시에만 관련되지 않습니다. Warning섹션 의 첫 번째 문장 은 "경고는 캐시 관련 및 기타 용도로 사용할 수 있습니다."입니다.
Çelebi Murat

37

410 (Gone)을 사용할 수 있습니다 .

W3C의 상태 코드 정의에서 설명 하는 방법은 다음과 같습니다 .

410 (사라짐)

요청 된 리소스는 더 이상 서버에서 사용할 수 없으며 전달 주소를 알 수 없습니다. 이 상태는 영구적 인 것으로 간주됩니다. 링크 편집 기능이있는 클라이언트는 사용자 승인 후 Request-URI에 대한 참조를 삭제해야합니다. 서버가 조건이 영구적인지 여부를 알지 못하거나 결정할 기능이없는 경우 대신 상태 코드 404 (찾을 수 없음)를 사용해야합니다 (SHOULD). 이 응답은 달리 표시되지 않는 한 캐시 할 수 있습니다.

410 응답은 주로 수신자에게 리소스를 의도적으로 사용할 수없고 서버 소유자가 해당 리소스에 대한 원격 링크를 제거하기를 원한다는 것을 통지함으로써 웹 유지 관리 작업을 지원하기위한 것입니다. 이러한 이벤트는 제한된 시간, 프로모션 서비스 및 더 이상 서버 사이트에서 일하지 않는 개인의 리소스에 대해 일반적입니다. 영구적으로 사용할 수없는 모든 리소스를 "사라짐"으로 표시하거나 일정 기간 동안 표시를 유지할 필요는 없습니다. 이는 서버 소유자의 재량에 달려 있습니다.


36
410의 문제는 '지원 중단 예정'요구 사항과 일치하지 않는다는 것입니다. API가 없어지면 제대로 작동하지만 나중에 없어 질 것이라는 점 아닙니다 .
Julien Genestoux 2014 년

3
410을 반환하면 이전 버전과의 호환성이 깨집니다
BenC

4
410 Gone폐기에 관한 것이 아니라 더 이상 사용할 수없는 방법에 관한 것입니다. @BenC가 말했듯이 더 나은 방법은 Warning 헤더
sempasha

2
이 사용되지 않는 API의 다음 단계가 될 수
Shiplu Mokaddim

16

나는 301 (영구 이동) 과 함께 갔을 것이다 . 300 시리즈 코드는 클라이언트에게 그들이해야 할 일이 있음을 알려야한다.


4
그것은 아마도 엔드 포인트가 실제로 제거되면 사용할 것이지만 필요한 변경을 수행 할 수 있도록 잠시 동안 알림을받을 수있는 기회를주고 싶습니다 (응답에서 HTTP 헤더를보고 있다고 가정). 그들의 끝.
BlazingFrog

2
이사 갈 지위가 정말 없습니다. 302 (요청 된 리소스가 일시적으로 다른 위치에 있지만 요청 된 URI에서 여전히 찾을 수 있습니다.) ...
u07ch

1
상태를 찾는 것이 아니라 응답에 추가 할 "표준"헤더를 찾습니다.
BlazingFrog

1
이러한 종류의 응답에는 표준 헤더가 없습니다. 자신의 헤더를 만들고 자신의 API 문서에 설명해야합니다.
Brian Kelly

응답 코드> = 300이면 문제가 발생한다고 생각합니다. 299를 사용하면 클라이언트가 필요한 변경을 수행하는 동안 API가 비활성화 될 때까지 애플리케이션을 활성 상태로 유지할 수 있습니다.
devlord

6

207 Multi-Status성공적인 응답임을 나타내는 응답을 권장 하지만 잠재적으로 두 번째 사용되지 않는 상태가 있습니다.


1
흥미 롭군. 나는 그것에 대해 몰랐지만 실제로 는 여전히 200 범위에 있더라도 다른 응답 코드로 교체하여 일부 클라이언트에 대한 주요 변경 사항을 도입 할 강력한 위험이 있다고 생각 합니다. 압력을 약간 덜어 주실 수있을 것 같습니다. Deprecation(클라이언트는 불행히도 무시할 가능성이 있는) 헤더로 시작한 다음 나중에이 207 코드를 사용하고 나중에 301이 이동 한 다음 마지막으로 410이 사라졌습니다!
Harry Wood

4

@dret의 응답을 구체화합니다. 지원 중단과 관련된 두 가지 HTTP 헤더 Deprecation( https://tools.ietf.org/html/draft-dalal-deprecation-header-00 ) 및 Sunset.

사용자에게 예정된 지원 중단에 대해 알리려면 DeprecationHTTP 헤더를 사용해야합니다. 이는 엔드 포인트가 향후 언젠가 삭제 될 것임을 나타냅니다 . 또한 이것이 발표 된 날짜를 표시하고 대체 리소스를 설명 할 수 있습니다.

지원 중단 된 리소스의 예정된 지원 중단 날짜를 사용자에게 알리려면 SunsetDeprecation 헤더와 함께 헤더를 사용해야합니다. 이는 섹션 # 5 https://tools.ietf.org/html/draft-dalal-deprecation-header-00#section-5에 설명되어 있습니다 .

헤더 의 초안 # 11 https://tools.ietf.org/html/draft-wilde-sunset-header-11Sunset 은이 측면을 1.4 섹션 https://tools.ietf.org/html/draft-wilde 에서도 명확히 설명합니다. -sunset-header-11 # section-1.4 .


3

Sunset리소스의 향후 지원 중단을 알리기위한 HTTP 헤더 필드 가 있습니다. https://tools.ietf.org/html/draft-wilde-sunset-header 는 RFC가되는 마지막 단계에 있습니다. 이상적으로는 API가를 사용할 것임을 문서화하여 Sunset클라이언트가 원하는 경우이를 찾아 조치를 취할 수 있도록해야합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.