웹 API 사용 중단 : 모범 사례?

결국 공개 웹 API의 일부를 감가 상각해야합니다. 그러나 최선의 방법이 무엇인지 혼란 스럽습니다. 대규모 타사 앱 기반을 사용하는 경우 거의 모든 앱이 밤새 실패하므로 이전 버전의 API를 잡아 당기는 것은 잘못된 방법으로 보입니다. 그러나 고대 웹 API는 오래되거나 오래 사용할 수 없으므로 중요한 변경 사항이 있기 때문에 영원히 사용할 수는 없습니다.

오래된 웹 API를 더 이상 사용하지 않는 모범 사례는 무엇입니까?

원래 포스터는 이미 효과적이지만, 비공식적으로 API ( '오래된 API'라고 함)는 더 이상 사용되지 않습니다. 그러나 API가 발표되고 사용자에게 API가 더 이상 사용되지 않는다는 알림이 표시 될 때까지 공식적으로 사용되지 않습니다.

더 이상 사용되지 않는 API는 임시로 비활성화 된 코드 단계입니다. 마지막 예식입니다. 이 기간은 채택 자 / 소비자가 새로운 API를 위해 앱을 재구성하고 좋아하는 작별을 고를 수있게하여 API와 평화를 이루는 기간입니다. 일부 API는 다른 API보다 오래 머무를 수 있지만이 시점에서 시간이 오래 걸리지 않습니다.

삭제 된 API는 코드 장례식입니다. 더 이상 할 수는 없지만 올바르게 처리하고 적절하게 기념합니다.

많은 API 및 서비스 개발자는 마지막 예식을 수행하지 않고 코드 장례식을 선택합니다. 그러나 나는 그것이 다소 위험하다고 생각합니다. API / 서비스가 처음 채택되거나 갱신 될 때 어떤 종류의 서비스 나 지원 약속이 있었다면, 장례식을 수행하기 전에 합당한 시간 동안 그 약속을 존중할 수 있습니다.

비 서비스 라이브러리의 경우, 기간에 관계없이 하나의 주요 릴리스 버전은 아마도 이전 버전과의 호환성을 보장하는 허용 가능하고 공정한 기간 이상이라고 생각합니다. 그 외에도 사용자의 영향력과 로비에 의존하여 그 기간을 넘어 수명을 연장합니다. 또한 교체 할 수없는 타사 의존성이 얽히고 특정 플랫폼의 특정 버전에 묶여있어 이의가있는 경우 놀라지 마십시오.

서비스의 경우, 서비스를 소비 할 수있는 사람과 방법에 따른 차이와 프로젝트 소비에서 프로젝트 소비까지의 해당 개발주기 차이로 인해 6 개월 또는 1 년 기간을보고 싶을 것입니다. 서비스를 소비하는 많은 프로젝트는 여전히 큰 초기 설계를 할 수 있으며 1 년 이상 릴리스주기를 예약 할 수 있습니다. 대부분의 개발자 의견에 따르면 일정이 긴 사람들은주기 시간을 맞출 책임이 있으며주기가 오래 걸리는 프로젝트는 더 빠른 릴리스주기를 채택해야하며 이는 사실 일 수 있습니다. 그러나 궁극적으로 삭제 날짜는 사용자와 협상해야하는 내용입니다.

더 이상 사용되지 않는 비추천 전략은 더 이상 사용되지 않을 때, API 섹션의 설문 조사 형식으로 의견 또는 이의 제기 요청과 함께 삭제하려는 시간 프레임을 강조 표시하는 것입니다. 서비스가 [세미] 익명 액세스로 작동하기 때문에 사용자의 대화 상대 목록이없는 경우, 자주 활동중인 사용자에 대한 로그를보고 호스트 또는 도메인 관리자에게 알림을 전달하여 적절하다고 판단 될 수 있습니다.

내가 사용하는 대부분의 웹 API (Google, Yahoo! 및 Microsoft와 같은 회사에서 사용)는 "일몰"기간이 있습니다. 개발자는 사전에 업그레이드 할 충분한 시간을 제공하기 위해 감가 상각 될 기능에 대해 적절한 시간 (3-6 개월) 내에 정보를받습니다.

서비스 약관 또는 기타 문서에 일몰 기간에 대한 세부 정보를 추가하여 사람들이 작동 방식을 알 수 있습니다. 이는 누군가 API를 사용하기로 결정할 때 어떤 일정을 처리해야하는지 알게 될 것입니다. 예를 들어, 사람들에게 1 년에 한 번 시스템을 업그레이드해야하며 4 개월 전에 통지해야한다고 알릴 수 있습니다.

또한 버전 번호 매기기를 사용하는 것이 좋습니다. 예를 들어 "버전 3은 곧 감가 상각 될 예정이므로 코드가 버전 4에서 작동하는지 확인하십시오"등입니다. 응용 프로그램이 버전에서 작동하는 경우 4 그러면 일몰 준비가되었습니다.

프로세스 각도의 추가 정보 :

• 모든 이해 관계자와 의사 소통 : 다른 팀 및 API 소비자에게 API를 사용하지 않는 이유, 전략, 계획 및 일정 세부 정보, 버전 지정 의미 및 대안에 대해 명확하고 간결한 의사 소통을 제공하고 이에 따라 HTTP를 설정하십시오.

• 계획 및 일정 : 계획에서 주요 이정표 및 사용 중단 예정일이 있어야합니다. 소비자에게 동일하게 요청하고 전화를 더 이상 사용하지 않는 날짜를 제공해야합니다. 프로세스를 모니터링하고 소비자를 지원하기 위해 정기적 인 회의를 주최하십시오.

• 버전 관리 및 대안 제공 : 버전 관리는 주요 릴리스의 주요 변경 사항을 표시하고 API 지원 중단 전략을 세우는 데 도움이 될 수 있습니다.

• Sunset HTTP 응답 헤더 설정 : HTTP 헤더는 경고의 기술적 부분을 담당하므로 API 소비자는 API가 더 이상 사용되지 않는시기를 이해하기 위해이 유형의 코드를 모니터링해야합니다.

• 사전 및 사후 모니터링 : 소비자를 모니터링하고 특정 기간이 지난 후에도 여전히 API를 사용하는 소비자에게 유용한 정보를 제공하여 포기를 놓치지 않도록 경고합니다.

기존 답변 외에도 무언가를 제거 할 때 드롭 인 대체 또는 마이그레이션 계획을 제공하여 사용자가 코드를 업데이트 할 수 있도록해야합니다.

대안을 제공하지 않고 기능을 제거하지 마십시오. 이로 인해 일부 사용자는 불만을 느낄 수 있습니다.