"공용 API는 영원합니다. 단 한 번의 기회 만이 맞습니다"?

OS 책에서 나는 "공용 API는 영원합니다. 단 한 번의 기회 만이 맞습니다"라고 읽었습니다. 사실인가요? 운영 체제의 API 또는 다른 API에만 적용 할 수 있습니까? 예를 들어 Tasker, Locale 및 Pushover와 같은 Android 응용 프로그램의 API에 해당됩니까?

일반적으로 모든 공용 API에 해당됩니다. API를 공개하고 사람들이 해당 API에 의존하는 응용 프로그램을 구축하기 시작하면 API를 변경하는 것이 매우 어려워집니다. 그렇게하면 해당 응용 프로그램이 모두 중단 될 수 있습니다. 그것은 어려운 기술적 문제와 어려운 정치 문제인 경향이 있습니다.

물론 공개 API를 변경할 수 있습니다. 예를 들어 프로젝트가 한 릴리스에서 API를 폐기하고 새 API를 도입 한 다음 향후 릴리스에서 이전 API를 제거합니다. 그러나 이전 API를 사용하기 전에 이전 API를 사용하는 모든 (중요한) 응용 프로그램이 새 API를 사용하도록 다시 작성된다고 가정합니다. 종종 몇 년이 걸립니다. 이는 공개 API 소유자가 API를 소비하는 다른 모든 프로젝트에 비용을 부과한다는 것을 의미합니다. 일반적으로 API 소비자가 훨씬 많기 때문에 이러한 소비자는 상대적으로 강력한 정치 로비 인 경향이 있습니다.

인용 저자는 Joshua Bloch이며, 그 진술은 Bumper-Sticker API Design 기사에서 발췌 한 것입니다.

다이아몬드와 같은 공개 API는 영원합니다. 당신은 그것을 올바르게 얻을 수있는 기회가 있으므로 최선을 다하십시오.

이에 대한 자세한 내용은 저자가 컨퍼런스 세션 프레젠테이션 인 "좋은 API를 디자인하는 방법과 중요한 이유"를 참조하십시오 . 슬라이드 API 디자인하는 것이 중요하다 왜 당신은 이 (저자에 상관하지 않는 운영 체제 여부) 프로그래밍 활동과 관련이 꽤 명확하게 진술한다 :

• 프로그래밍하면 API 디자이너입니다.

  • 좋은 코드는 모듈 식입니다-각 모듈에는 API가 있습니다

• 유용한 모듈은 재사용되는 경향이 있습니다

  • 모듈에 사용자가 있으면 마음대로 API를 변경할 수 없습니다
  • 좋은 재사용 가능한 모듈은 기업 자산입니다

• API 측면에서 생각하면 코드 품질이 향상됩니다.

슬라이드 결론 은 이것을 일반적인 접근 방식으로 강조합니다.

• API 디자인은 고귀하고 보람있는 기술입니다

  • 많은 프로그래머, 최종 사용자, 회사를 개선합니다 ...

API는 항상 변경됩니다. 그렇지 않으면 시스템 업그레이드의 요점은 무엇입니까? 내부 만 변경 하시겠습니까?

각 버전의 시스템은 새로운 API를 제공하며, 오래된 API는 더 이상 사용되지 않으며 사용되지 않는 API는 사라집니다.

API 변경은 기술적으로나 의사 소통 측면에서 매우 신중해야합니다.

내 의견은 API의 '버전'이 영원히 릴리스되었지만 '2.0'API를 릴리스하여 사용을 중단 할 수 있다고 생각합니다 (이 경우 몇 가지 예가 있습니다-현재 Strava를 출시 한 사람을 생각할 수 있습니다 서비스 소비에 대한 개발을위한 2.0 버전의 API).

문제는 원래 API 광고 인피니 엄을 지원하는 것입니다 ... 이전 API의 사용법과 API 소비자의 가치에 달려 있다고 생각합니다.

Windows 3.x 및 9x 등의 '이전 시대'로 돌아 가면 일단 릴리스되면 해당 OS API가 완료되고 설정됩니다. 이제 OS 업데이트가 항상 푸시되므로 새로운 API가 릴리스 될 수 있지만 특정 OS 특징 (주 릴리스)을 실행하는 한 해당 API는 추가되거나 절대 제거되지 않을 것이라고 생각합니다 ... 그래도 '다음'주요 릴리스의 경우입니다.

흠, 어쩌면 나는 원래의 질문 의도에서 벗어 났을 것입니다.

그것은 어떤 종류의 API인지에 달려 있습니다 (그리고 나는 변화를 겪고 있다고 가정하고, 그렇지 않으면 그 진술은 사실이 아닙니다).

호출자가 사용중인 버전을 선택할 수있는 경우 (예 : 호출 응용 프로그램과 함께 번들로 제공되는 라이브러리 / 프레임 워크) API를 변경하는 것은 큰 문제는 아니지만 여전히 소프트웨어의 명성에는 좋지 않습니다. 사람들은 원활하게 업그레이드하는 것을 좋아합니다.

반면에 사람들이 온라인 서비스 나 이전 버전을 실행하는 것이 매우 바람직하지 않은 브라우저 나 OS와 같이 이전 버전의 API를 계속 사용할 수없는 경우 호환되지 않는 방식으로 API를 변경하는 것은 매우 나쁩니다. 실제로, 그것을 사용하고 업데이트되지 않는 모든 소프트웨어를 손상시킬 것이기 때문입니다. 이것은 개발자에게 유지 보수 비용을 부과하고, 당신을 미워할 것입니다. 유지 관리되지 않고 중단 된 소프트웨어는 사용자에게 크게 반영되지 않습니다.

어쨌든 API의 주요 변경 사항 을 지속적으로 도입하고 어쨌든 페이스 북 (Facebook)에 성공한 API 공급자가 적어도 하나 있습니다. 그러나 변경 사항을 매우 신중하게 관리합니다. 게시 된 정책이 있으며, 최소 90 일 전에 변경 내용이 발표되고 설명되며 개발자는 해당 기간 내에 초기에 변경 사항을 활성화 할 수 있습니다.

API 자체에 버전 번호를 포함시킬 것으로 예상되는 경우. 연결 / 초기화 호출 또는 각 호출의 매개 변수 목록 시작 부분 근처에서 API는 기존 클라이언트를 방해하지 않고 시간이 지남에 따라 진화하고 변경 될 수 있습니다.

비록 우리가하는 모든 일이 한 번에 최선을 다하는 것이지만, 시간이 바뀌고 개선되기 시작한 이래로, 많은 거대한 제공자들이했던 것처럼 정보를 업데이트해야 할 때가 있습니다 (페이스 북 여러 업데이트, 트위터 하나의 주요 oAuth와 몇 가지 전공으로 전환하지만 최대한 자주 개선 사항이 제공되므로 자주 변경하지 마십시오. 그렇습니다. 오래된 지원을 중단하지 마십시오.

분명히 API를 포함하는 모든 종류의 통신 프로토콜을 릴리스 할 때마다 프로토콜 / 인터페이스가 이전 버전과 호환되고 확장 가능해야한다는 의미에서 올바르게 사용할 수 있습니다.

이를 통해 이전 버전을 사용하는 사람들을 망칠 걱정없이 새로운 기능을 추가하고 새 버전을 출시 할 수 있습니다. 소프트웨어 세계에서는 결코 특정 시점에서 하드 컷 오버를 할 수있는 상황이 아니며 모든 사람이 이전 버전을 삭제하고 새 버전을 사용하기 시작합니다.