「パブリックAPIは永遠に存在します。正しく機能するチャンスは1つだけですか？」

OSの本で、「パブリックAPIは永遠に存在します。それを正しく実現するチャンスは1つだけです」と読みました。本当ですか？オペレーティングシステムのAPIまたは他のAPIにも適用できますか？たとえば、これはTasker、Locale、PushoverなどのAndroidアプリケーションのAPIに当てはまりますか？

はい、パブリックAPIには一般的に当てはまります。APIを一般に公開すると、そのAPIに依存するアプリケーションの構築が開始されると、APIを変更することが非常に難しくなります。変更すると、それらのアプリケーションがすべて壊れてしまうからです。それは難しい技術的問題と難しい政治的問題の両方になる傾向があります。

もちろん、パブリックAPIを変更することは可能です。たとえば、プロジェクトが1つのリリースで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について考えることができます）開発用のAPIの2.0バージョン（サービスを消費するため）。

問題は、その元のAPI広告を無限にサポートしていることです...それは、古いAPIの使用法と、それらのAPIコンシューマーの価値があなたに保持しているものに依存していると思います。

たとえば、Windows 3.xや9xなどの「昔」に戻って、リリースされると、これらのOS APIが完成して設定されました。現在、OSの更新は常にプッシュされるため、新しいAPIをリリースできますが、特定のOSフレーバー（メジャーリリース）を実行している限り、これらのAPIは追加されるだけで、削除されることはありません...ただし、「次の」メジャーリリースの場合です。

うーん、元の質問の意図から外れたのかもしれません。

それはそれがどんな種類のAPIであるかに依存します（そして、私は破壊的な変更を仮定しています、さもなければステートメントは明らかに真実ではありません）。

呼び出し元が使用しているバージョンを選択できる場合（たとえば、呼び出し側アプリケーションにバンドルされているライブラリ/フレームワークで）、APIの変更は大きな問題ではありませんが、ソフトウェアの評判にはまだ悪いです。人々はシームレスにアップグレードしたいです。

一方、人々が古いバージョンのAPIを使用し続けることができない場合（オンラインサービス、または古いバージョンの実行が望ましくないブラウザやOSなど）、互換性のない方法でAPIを変更することは非常に悪いです実際、それを使用するすべてのソフトウェアが破損し、同様に更新されないためです。これにより、開発者にメンテナンスコストがかかり、開発者はそれを嫌います。そして、メンテナンスされておらず壊れているソフトウェアもあなたにひどく反映されます。

一方で、APIの絶え間ない変更を常に導入し、とにかく途方もなく成功している少なくとも1つのAPIプロバイダー、Facebookがいます。ただし、変更は非常に慎重に管理されます。ポリシーが公開されており、少なくとも90日前に重大な変更が発表および説明されます。

API自体にバージョン番号を含める先見性がある場合。接続/初期化呼び出し、または各呼び出しのパラメーターリストの先頭近くのいずれかで、既存のクライアントを中断することなく、APIを時間の経過とともに進化させ、変化させることができます。

私たちがすることはすべて一度に最高のものにすることですが、時間の変更と改善が来るので、多くの巨大なプロバイダーが行っているように、時々情報を更新する必要がありますoAuthといくつかのメジャーに目を向けますが、可能な限りすべて改善されているため、頻繁に変更されることはありません。

明らかにAPIを含むあらゆる種類の通信プロトコルをリリースするときはいつでも、プロトコル/インターフェースが下位互換性と拡張性を備えている必要があるという意味で、それを正しく実現する機会が1つあります。

これにより、古いバージョンを使用しているユーザーを壊す心配をせずに、新しい機能を追加して新しいバージョンをリリースできます。ソフトウェアの世界では、特定の時点でハードカットオーバーを行うことができ、古いバージョンを削除して新しいバージョンの使用を開始する状況になることはありません。