REST API 엔드 포인트를 업그레이드 중이며 더 이상 사용되지 않는 엔드 포인트를 호출 할 때 클라이언트에게 알리고 싶습니다.
"이 API 버전은 더 이상 사용되지 않습니다. 최신 문서를 참조하여 엔드 포인트를 업데이트하십시오."라는 메시지와 함께 응답에 어떤 헤더를 사용해야합니까?
REST API 엔드 포인트를 업그레이드 중이며 더 이상 사용되지 않는 엔드 포인트를 호출 할 때 클라이언트에게 알리고 싶습니다.
"이 API 버전은 더 이상 사용되지 않습니다. 최신 문서를 참조하여 엔드 포인트를 업데이트하십시오."라는 메시지와 함께 응답에 어떤 헤더를 사용해야합니까?
답변:
이전 버전과 호환되도록 상태 코드에서 아무것도 변경하지 않을 것입니다. 응답에 "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"을 제안합니다.
Date
헤더 와 동일한 방식으로 형식을 지정해야합니다 "Thu, 02 Apr 2015 12:25:32 GMT"
..
Warning
헤더는 지원 중단을 설명하는 자유 텍스트 위치로 잘 보입니다. Deprecation
과 Sunset
다른 답변에서 언급 한 헤더는 엄격한 더 잠재적으로 기계 판독 방법으로 사용되지 않음을 설명하기위한 새로운 표준 솔루션이 될 것 같다.
Warning
헤더는 캐시에만 관련되지 않습니다. Warning
섹션 의 첫 번째 문장 은 "경고는 캐시 관련 및 기타 용도로 사용할 수 있습니다."입니다.
410 (Gone)을 사용할 수 있습니다 .
W3C의 상태 코드 정의에서 설명 하는 방법은 다음과 같습니다 .
410 (사라짐)
요청 된 리소스는 더 이상 서버에서 사용할 수 없으며 전달 주소를 알 수 없습니다. 이 상태는 영구적 인 것으로 간주됩니다. 링크 편집 기능이있는 클라이언트는 사용자 승인 후 Request-URI에 대한 참조를 삭제해야합니다. 서버가 조건이 영구적인지 여부를 알지 못하거나 결정할 기능이없는 경우 대신 상태 코드 404 (찾을 수 없음)를 사용해야합니다 (SHOULD). 이 응답은 달리 표시되지 않는 한 캐시 할 수 있습니다.
410 응답은 주로 수신자에게 리소스를 의도적으로 사용할 수없고 서버 소유자가 해당 리소스에 대한 원격 링크를 제거하기를 원한다는 것을 통지함으로써 웹 유지 관리 작업을 지원하기위한 것입니다. 이러한 이벤트는 제한된 시간, 프로모션 서비스 및 더 이상 서버 사이트에서 일하지 않는 개인의 리소스에 대해 일반적입니다. 영구적으로 사용할 수없는 모든 리소스를 "사라짐"으로 표시하거나 일정 기간 동안 표시를 유지할 필요는 없습니다. 이는 서버 소유자의 재량에 달려 있습니다.
410 Gone
폐기에 관한 것이 아니라 더 이상 사용할 수없는 방법에 관한 것입니다. @BenC가 말했듯이 더 나은 방법은 Warning 헤더
나는 301 (영구 이동) 과 함께 갔을 것이다 . 300 시리즈 코드는 클라이언트에게 그들이해야 할 일이 있음을 알려야한다.
207 Multi-Status
성공적인 응답임을 나타내는 응답을 권장 하지만 잠재적으로 두 번째 사용되지 않는 상태가 있습니다.
Deprecation
(클라이언트는 불행히도 무시할 가능성이 있는) 헤더로 시작한 다음 나중에이 207 코드를 사용하고 나중에 301이 이동 한 다음 마지막으로 410이 사라졌습니다!
@dret의 응답을 구체화합니다. 지원 중단과 관련된 두 가지 HTTP 헤더 Deprecation
( https://tools.ietf.org/html/draft-dalal-deprecation-header-00 ) 및 Sunset
.
사용자에게 예정된 지원 중단에 대해 알리려면 Deprecation
HTTP 헤더를 사용해야합니다. 이는 엔드 포인트가 향후 언젠가 삭제 될 것임을 나타냅니다 . 또한 이것이 발표 된 날짜를 표시하고 대체 리소스를 설명 할 수 있습니다.
지원 중단 된 리소스의 예정된 지원 중단 날짜를 사용자에게 알리려면 Sunset
Deprecation 헤더와 함께 헤더를 사용해야합니다. 이는 섹션 # 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 .
Sunset
리소스의 향후 지원 중단을 알리기위한 HTTP 헤더 필드 가 있습니다. https://tools.ietf.org/html/draft-wilde-sunset-header 는 RFC가되는 마지막 단계에 있습니다. 이상적으로는 API가를 사용할 것임을 문서화하여 Sunset
클라이언트가 원하는 경우이를 찾아 조치를 취할 수 있도록해야합니다.
Date
동일한 메시지 의 값과 다른 경고 날짜를 수신 하면 수신자는 경고 값을 제외해야합니다. . . 전에. . . 메시지를 사용합니다.”