Web開発における.NET API：過去と未来

多くの人々は、APIの作成は特定のプロセスであり、APIプロジェクトの開発に専門的に関与している人だけがそれを理解する必要があると考えています。 しかし、実際には、APIをなんらかの方法で作成します。新しいクラス、サービス、同僚や顧客向けです。



カットの下で、Web APIデザインの作成、変更の計画、バージョニングの管理、APIユーザーとの対話方法に関する実用的なヒントを見つけようとしました。 私たちは、どのような困難が生じる可能性があり、どんな典型的な間違いが通常なされるかを見つけようとしました。 また、歴史からのさまざまな興味深い事実や、将来の予想される変化についても読んでください。



私たちの対談者であるディラン・ビーティーは、 StackOverflowで高い評価を得ています。つまり、彼は、うまく、面白い、そして重要なことに、質問に正しく答える方法を知っています。 素晴らしい経験により、彼は彼自身の例を使って過去から何かを語ることができ、建築家の職業は彼の口調を保ち、トレンドと高度な技術に関する新しい知識をもたらします。







-どのAPIを開発していますか？ APIの設計はどの時点で突然ソフトウェア開発に移行しますか？



Dylan Beatty：これは非常に興味深い質問です。ソフトウェア開発の分野での最大の誤解の1つは、APIの設計が他のすべてとは別に発生するものだと思うからです。 もちろん、HTTP APIなどの特定の種類のAPIプロジェクトは一般公開されますが、設計を作業の別の部分と見なすことは理にかなっています。 しかし、実際には、ほとんどの開発者は、実際に常にAPIを作成します。彼らは、APIを実行していることに気付かないのです。 クラスの1つでパブリックメソッドを記述するか、データベーステーブルの名前を選択するたびに、インターフェースを作成します-通常の日常的な英語の意味で-これは、将来特定の時点で他の開発者によって最終的に使用されるものです。 チームの他の人がクラスとメソッドを使用します。 他のコマンドは、データスキームまたはメッセージ形式を使用します。



興味深いのは、開発者が作業中のコードがAPIの一部になる可能性があることを理解している場合、開発者は同じ方向に行き過ぎているということです。 エッジケースや、実際には必要のないその他のあらゆる種類の実装を開始します。単に後で他の人が必要になる可能性があるためです。 ここでラインを微妙に感じる必要があると思います。このラインを理解するための鍵は、あなたが今必要な関数のセットを作成する際に非常に具体的である必要があることです。 ただし、このセットを可能な限り再利用可能かつ自己記述的にすることが重要です。 Pieter Hintjensには、良いAPI設計のための10のルールと呼ばれる優れたエッセイがあり、このタイプのアイデアのより詳細なビューを提供します。



私が現在取り組んでいる最大のAPIプロジェクトは、イギリスのSpotlightで行っているプロジェクトです。 これは、プロの俳優に関するさまざまな情報を明らかにするハイパーメディアAPIです。 仕事は、演技プロジェクト、映画やテレビ、およびキャスティング業界で使用されるその他のさまざまなデータで提供されています。 RESTとして知られるアーキテクチャスタイルでこのAPIを構築しています。RESTが何であるかを完全に認識していない場合は、サンクトペテルブルクで開催されるDotNextカンファレンスで私のプレゼンテーションにアクセスし、それについて調べるだけです。



HTTP APIを作成するためのさまざまなパターンがあります-RESTがあり、GraphQLがあり、SOAPやRPCなどがあります。 しかし、私にとって、RESTの最大の魅力は、RESTfulスタイルの制限により、APIがサポートする必要がある概念と操作の接続が自然に弱くなることです。



-下位互換性によって「殺される」最も有名なプログラムの1つはIEです。 このブラウザには、以前のバージョンとの互換性を維持するために必要なアプリケーションが多すぎました。 この問題は、Edgeと呼ばれる新しいアプリケーションを追加することで解決されました。このアプリケーションは更新され、すべての新しい標準をサポートします。 後方互換性のtrapに陥らないようにするには？ たぶん、モジュールを使用する価値がありますが、モジュールはレイヤーを使用しませんか？ あるいは、RESTful API、Service Oriented Architecture、または他の何かを使用して、どういうわけかAPIを置き換えますか？



Dylan Beatty：ずっと前にWebアプリケーションの構築を始めました。 彼はInternet Explorerが登場する数年前に最初のページを書きました。 そして、唯一のブラウザがNCSA MosaicとErwiseだったとき。 Webの歴史を振り返ると、現在存在するWebがInternet Explorerのようなものによってモデル化され、影響を受けていることに気付くのは魅力的です。 そして、あなたは絶対に正しいです。 Microsoftが最新バージョンのWindowsにまったく新しいEdgeブラウザーを導入した理由の1つは、Internet Explorerの下位互換性への取り組みが、既存のIEコードベースに基づく新しいWeb標準の実装を非常に困難にしたためです。



IEにこの下位互換性が存在する理由の一部は、2000年頃に企業のITシステムの開発方法にわずかな変化があったことです。



エクイティコントロール、プロダクトアカウンティング、HR、プロジェクト管理など、さまざまなタイプのビジネスオペレーションに独自のアプリケーションを使用している企業は無数にあります。 1980年代から1990年代初頭にかけて、それらのほとんどは中央のメインフレームシステムを使用し、従業員はターミナルエミュレータのようなものを使用して中央のサーバーに接続していました。 しかし、1990年代後半のドットコムの最初の波の後、企業はほとんどのコンピューターがWebブラウザーとネットワーク接続を備え、古いメインフレーム端末アプリケーションを新しいWebアプリケーションに置き換えることができることに気付きました。



当時のWindowsは大きな市場シェアを占めており、ほとんどのWindows PCでInternet Explorerがデフォルトのブラウザーであったため、多くの組織はInternet Explorerの特定のバージョンでのみ動作するイントラネットアプリケーションを構築しました。 ActiveXサポートなどの特定の機能を利用するために、これを行うことがありました。 しかし、多くの場合、クロスブラウザテストを実施する必要がないという事実のために、彼らはお金を節約するためにそれをしたと思います。 これは、かなり大きな商用アプリケーションで発生しました。 2011年であっても、Microsoft Dynamics CRMはInternet Explorer以外のブラウザーをサポートしていませんでした。



そのため、Internet Explorerで動作するアプリケーションの作成に時間とお金を費やした多くの企業があります。 これらのアプリケーションは、Web標準や漸進的な改善を使用して作成されたものではなく、後続バージョンとの互換性を作成しようとするものでもありません。オペレーティングシステムで実行される特定バージョンのブラウザー用に明示的に開発されました。 また、MicrosoftがInternet Explorerの新しいバージョンをリリースするたびに、これらのアプリケーションは「クラッシュ」し、企業は古いイントラネットアプリケーションの更新に投資することを望まず、すべてをブラウザーのせいにしました。 しかし、話は終わりではありません。2017年には、MicrosoftはまだIE11を出荷しています。IE11は、IE9エンジンに切り替える互換モードを備えていますが、IE7であるというユーザーエージェント文字列を送信します。 現在、私が知っているすべての人がGoogle ChromeまたはSafariを使用してネットサーフィンをしていますが、同時に、多くの人々はまだデスクトップにIEショートカットを持っているので、そこからレガシーシステムの1つを入力できます。



だから...マイクロソフトがこのtrapをどのように回避できたのかという質問に戻ります。 多くの機会があったと思います。 または、最初にモジュラーレンダリングエンジンを使用してIEを作成し、後続のバージョンが適切なエンジンを選択的に実行して特定のWebサイトまたはアプリケーションをレンダリングできるようにします。 MARQUEEタグやActiveXプラグインなどのアドホックサポートを実装する代わりに、当時存在していたWeb標準をサポートするためにもっと努力することができたでしょう。これにより、これらの難解な機能をサポートした後の頭痛を回避できますバージョン。 しかし、これはすべて意味がありません。 Internet Explorerの最初のバージョンを開発するとき、Web標準を一流でサポートする優れたアプリケーションを作成するのではなく、Netscape Navigatorを殺して市場セクションで勝つことが重要でした。 そしてそれは働いた。



-誰かが新しいAPIを導入しようとしているとします。 彼はいくつかの要件を収集し、バージョンを提供し、フィードバックを受け取ります。 プロセスはシンプルに見えます。 しかし、途中で落とし穴はありますか？



ディラン・ビーティ：いつも！ 要件が変更されます-これは事実です。 あなたが犯す可能性がある最大の間違いの1つは、これらの変更を予測し、将来を見越した設計を行うことです。 理論的にはこれで成果が得られる可能性がありますが、多くの場合、将来の変更を取り入れようとしたため、さらに複雑なデザインが手元にあります。 多くの場合、落とし穴はあなたが制御できないものです。 たとえば、法律が変わり、データを異なる方法で提供する必要があります。 または、組織内の他のシステムに変更が加えられます。 または、クラウドホスティングプロバイダーの1つから、必要な機能が廃止されたカテゴリーに移行されたと言われます。



可能なインターフェースオプションからシンプルで使いやすいものを選択し、それを実行して渡すことが最善です。 APIが安定している段階に迅速に進むために、外部の技術的な負債はなく、チームは次のタスクに進むことができます。 そのため、その後予期せぬ問題が突然発生した場合、ソリューションで使用できる安定したコードベースと、すべてを解決するために時間と意欲を持っているチームができます。 偶然に落とし穴に出会わない場合は、単にバックログの次の項目に進むことができます。



-ここでは、APIのバージョンv1.0およびアプローチv1.1をリリースしました。 おそらく私たちの多くは、 http：//example.com/v1/testとhttp://example.com/v1.1/testまたはそのようなものの両方を作成します。 あなたの意見では、開発者がv1.0に関してv1.1 API設計を改善するのに役立つプラクティスは何ですか？



Dylan Beatty：セマンティックバージョニング（SemVer）の概念を読んで、メジャーバージョン、マイナーバージョン、およびパッチバージョンの違いを実際に理解してください。 SemVerは、0.xから0.1の間で重大な変更を行うべきではないと述べているため、最も重要な部分は、特定のAPIの重大な変更を理解することです。



たとえば、JSONを返すHTTP APIを使用する場合、一般的な重要ではない変更は、リソースの1つに新しいデータフィールドを追加することです。 バージョン1.1を使用するクライアントには追加フィールドが表示され、このフィールドを最大限に活用できることが期待されますが、バージョン1.0を使用する顧客は認識されないプロパティを無視できます。 これは、APIのバージョン管理をどのように管理すべきかについてのもう1つの非常に近い質問です。 最も一般的なソリューションの1つは、ルーティングを介してURLを送信することです-api.example.com/v1.1の代わりにapi.example.com/v1/



ただし、RESTfulシステムの制限に準拠する場合は、バージョンの変更が基礎となるリソースまたはビューの変更を表すかどうかを理解する必要があります。 URIはUniform Resource Identifierであり、同じリソースに向けるために使用するURIを実際に変更すべきではないことに注意してください。



たとえば、リソースapi.example.com/images/monalisaがあります。 このリソースをJPEG（Accept：image / jpeg）またはPNG（Accept：image / png）として要求するか、サーバーにこのリソースのプレーンテキスト表現があるかどうかを確認できます（Accept：application / json）-それだけです同じ基になるリソースの異なる表現のみであり、それらはすべて同じURIを持つ必要があります。



または、たとえば、組織で使用されているCRMシステムを完全に置き換えました。この場合、クライアントの「バージョン1」は古いCRMシステムで使用されていたレコードを表し、「バージョン2」は同じクライアントを表しますが、完全に新しいプラットフォーム。 この場合、おそらくそれらを異なるリソースと見なし、異なるURIを与えることが理にかなっています。



バージョニングは注意が必要です。 最も簡単な方法は、何も変更しないことです。



-.NET Core-そのAPIについてどう思いますか？

Dylan Beatty： .NET Coreは2015年に初めて発表され、当初は.NET Core 5.0と呼ばれていました。 これは、.NET FrameworkおよびCommon Language Runtimeの単純化された代替手段になると予想されていました。 .NET Coreを他のプラットフォームに移植しやすくするために、すべての条件を作成することは素晴らしいアイデアでした。 確かに、同時に、.NET Coreで開かれているAPIと、ほとんどのアプリケーションが構築されている「標準」の.NET / CLR APIとの間にはまだかなりの違いがあります。



これは、私が読んだことやさまざまな人々との会話に基づいた単なる解釈であると思います。アイデアは、.NET Coreがスレッド、ファイルシステムへのアクセス、ネットワークアクセス、プラットフォームベンダー、およびオープンソースコミュニティは、モジュールとパッケージの開発を既に開始しており、その結果、Javaクラスライブラリや.NET Frameworkなどのソリューションが提供する機能レベルに到達します。 原則として、これは素晴らしいアイデアですが、悪循環のようなものを作成します。ユーザーなしでプラットフォーム用のライブラリを作成したい人や、ライブラリなしでプラットフォームを使用したい人はいません。



そのため、クロスプラットフォームの.NETには、サポートされているさまざまなプラットフォームのユーザーや開発者が期待するライブラリを提供する標準API仕様が必要であると判断されました。 これは、.NET Framework 4.6.1で既に完全にサポートされている.NET Standard 2.0であり、.NET CoreおよびXamarinの将来のバージョンで完全にサポートされる予定です。 もちろん、.NET Core 1.1は既にリリースされており、正常に動作しています。WindowsまたはLinuxまたはmacOSを使用しているにもかかわらず、C＃Webアプリケーションを作成するために使用できるようになりました。 しかし、.NET Coreの次のリリースでは、フレームワークとパッケージの多くの開発者がプロ​​ジェクトを.NET Coreに移行したいと思うようになり、開発者や組織が独自のアプリケーションを簡単に移行できるようになると思います。



-APIの柔軟性とAPIの精度。 多くの異なるタイプの値を取得する機能を備えたAPIメソッド設計を作成できます。 ただし、パラメーターにいくつかのルールを指定してメソッドを作成できます。 両方のパスが正しいです。 これら2つの可能性の境界はどこにありますか？ いつ厳密なAPIを作成する必要があり、いつ柔軟なAPIデザインを作成する必要がありますか？



Dylan Beatty：メソッドシグネチャが柔軟なAPIを実装するときは、スタックのどこかに複雑さを送信するだけです。 スキーパスを見つけるためのAPIを作成し、DoSearch（SearchCriteria基準）とDoSearch（string resortName、string countryCode、int minAltitude、int maxDistanceToSkiList）のいずれかを選択するとします。

これらのメソッドの最初は非常に簡単に拡張可能です。 メソッドのシグネチャを変更せずにSearchCriteriaオブジェクトの定義を拡張できます。 ただし、この場合、特定のメソッドを変更するだけでなく、システムの動作も変更します。



対照的に、2番目のDoSearchメソッドのシグネチャに新しい引数を追加できます。 C＃などの言語を使用する場合は、引数にデフォルト値を指定できます。 そして、メソッドに新しい引数を追加しても、プロジェクト内で何も壊すことはありません。同時に、これらの同じ引数に適切なデフォルト値を設定します。



ある時点で、APIユーザーと通信し、APIがサポートする検索パラメーターを伝える必要があります。 そして、これを行うにはいくつかの方法があります。 NuGetパッケージとしてインストールされ、コードから使用される.NET APIを作成する場合、メソッドとパラメーターにXMLコメントを使用することは、APIにリクエストを行うときに指定する必要があるものをユーザーに伝えるための優れた方法です。 APIがHTTPサービスの場合、 SIRENなどのハイパーメディア形式に注意してください。これにより、サポートされるパラメーターと範囲を指定できます。



次の10年で、機械学習システムによって駆動されるAPIの完全に異なるカテゴリが登場し、一般に受け入れられている多くのAPI設計ルールが適用されなくなると思います。 通常の言語で必要なものを指定するだけのスキーチケット検索APIを突然取得しても、まったく驚きません。 メソッドシグネチャさえもありません-DoSearch（「スキーシャレー、フランスまたはイタリア、1400m以上、8ベッドルームで12人を眠る、2018年1月18〜25日から利用可能」）のようなものを呼び出すだけです。コアでは、システムがすべてを行います。 これらの機械学習の開発方法は刺激的です。 しかし、彼らのクリエイターは、さらに注目を集めるために、開発者とデザイナーのためにいくつかの興味深い変更を加えたいと考えています。



今年、ディランビーティーは再びロシアを訪問し、5月にサンクトペテルブルクで開催されるDotNextカンファレンスで講演します。そのため、 彼の新しいレポートを聞くだけでなく、彼に質問したり、ロンドン.NETユーザーグループに挨拶したりすることができます。