/ Flickr / faris algosaibi / cc
しかし、トルコの人形のように見えたこの車は、実際には巧妙な錯覚であることが判明しました。 「トルコ人」の手は、テーブルに座っている男性によって制御されていました。 これはすべて安価なトリックでした-デバイスの秘密は1850年にだけ明らかにされました。 それから、人類が世界のチェスのチャンピオンを打ち負かす機械を作ることに成功した瞬間まで、2世紀以上が過ぎました。 1996年、IBMのDeep Blueコンピューターは、Garry Kasparovとの試合に勝ちました。
ソース： ProgrammableWeb
その4年後の2000年に、Roy Fieldingは、REST APIアーキテクチャスタイルの基礎となる、アーキテクチャスタイルとネットワークソフトウェアアーキテクチャの設計に関する研究を発表しました。
同じ年に、Salesforceは販売自動化用のAPIの最初のバージョンをリリースしました。 その後、eBayプラットフォームが続き、次に他のインターネット企業が続きました。 市場参加者はすぐに、アプリケーションプログラミングインターフェイスが提供できる利点に気付きました。 APIの数は増え始めています。
新しい「自動」マシン
サービスの1つがそのインターフェイスを一般に公開すると、人がドキュメントを書いて共有します。 次に、別の人がすでにこのドキュメントを見つけ、得られた経験を使用して、このインターフェイスを処理できるプログラムを作成します。 人々はM2M通信の仲介者として行動することがわかります。 これはすべて、トルコのチェスプレーヤーのトリックに非常に似ています。
今日、APIを使用する際、エンジニアは次の点で困難に直面しています。
- 同期性
- バージョン管理
- スケーリング
- 検索する
同期性
今日、2つのマシンが互いに「会う」前に、APIドキュメントが作成され、配布されています。 書かれていることを人々が誤解する可能性があるという事実を無視しても、ドキュメントの変更に関連する問題があります。 APIドキュメントの調整は非常に難しく、クライアントの保守と更新はさらに困難です。
バージョン管理
RESTは、Web APIの成功に大きな役割を果たし、Webの基本と完全に調和しています。 ほとんどのAPIはRESTの原則に従っていないため、APIクライアントは多くの場合、使用されるインターフェイスに関連付けられています。 これにより、非常に脆弱なシステムが作成されます。
さらに、APIを変更した場合に既存のクライアントを更新するには、時間とお金を費やす必要があり、プロセス自体は非常に低速です。 このため、APIは進化しません。 代わりに、新しいAPIはそれらに基づいて構築され、コードベースを「汚染」します。
スケーリング
今日、ますます多くの企業が、ユーザーが関心を持つ可能性のあるすべてのタスクに対してAPIを作成しています。 多くの企業は単一のAPIから始めますが、その後は常によりパーソナライズされたソリューションを考え出します。
新しいAPIを作成するには、より多くのプログラマを雇う必要があります。 これにより、システムのメンテナンスの複雑さが増します。 ただし、ドキュメントの作成と読み取り、または既存のプロジェクトのAPIの変更への適応に関しては、採用する人数は関係ありません-作業のこの部分はうまく拡張できません。 加えて、誤解と定式化の異なる解釈の余地が常にあります-言語は操作の余地を与えすぎる可能性があります。
検索する
最後に、APIを見つける際の問題に注意する必要があります。 使用したいサービスがあることをどのようにして知ることができますか？ おそらく、独自のソリューションを作成するときに時間を節約するプロジェクトが既に存在する可能性があります。 市場に別のジオロケーションサービスが存在することは問題ではありません。その存在を確認するのは非常に困難です。 口コミと検索エンジンに依存する必要があります。
可能な解決策
「完全に自律的なAPIを作成するには、検索エンジンがAPIに関連付けるドメイン辞書を開発して配布する必要があります」 と Good APIコンサルティング会社の創設者であるZdenek Nemecは述べています。
自律システムの動作は次のようになります。
- マシンは、インターフェースとドメインディクショナリを記述したプロファイルとともに、インターフェースを公開します。 その後、彼女はAPI検索サービスに登録します。
- 次に、別のマシンが辞書の用語を使用して検索サービスをポーリングします。 それらを使用するAPIが見つかった場合、検索サービスは目的のサービスの存在を報告します。
- これで、クライアントは自分のニーズに合わせてAPIを使用できるようになりました（要求されたディクショナリで動作するように既に「トレーニング」されていると考えられます）。
たとえば、特定のサービスの天気予報アプリケーションを開発する必要はなくなりました。 代わりに、天気予報の表示方法を知っているクライアントを作成し、AccuWeather、Weather Underground、および同じ辞書を使用する他の天気アプリケーションと「通信」します。
「そして、そのようなシステムを作成するためのビルディングブロックはすでに現れ始めています」とZdenek氏は指摘します。 -たとえば、HATEOASコントローラーはハイパーメディア形式の1つを使用して配布され、JSON-LD形式の適応はすでにAPI業界で人気を集めており、検索プロバイダーのGoogle、Microsoft、Yahoo、YandexはSchema.org辞書をサポートしています。 最後に、 HitchHQやRapid APIなどのAPIが登場し始めています。
おそらく将来、APIにより、ドキュメントや検索の問題からヒューマンファクターを除外できるようになり、辞書やその他の公開情報を使用して宣言的にAPIクライアントのプログラミングを開始する予定です。 これにより、新しい力により、接続されたデバイス、無人車両、高度な医療技術の開発を開始できます。
IT-GRAD 仮想インフラストラクチャプロバイダーのブログのその他の資料：