API を本番環境に導入する

「API のビルド方法」を Web 検索すると、かなりの数のオプションが表示されることがわかりましたが、エンド ツー エンドのガイドはほとんどありません。これは、私の Web 検索能力が低いためか、API を作成する (設計から実稼働まで) のが非常に難しいためである可能性があります。

API を扱っている人なら誰でも、それはかなりの偉業であり、通常は人々のチームがそれを管理していると言うでしょう。そのため、自分で API を構築し、それを本番環境に導入して、ユーザーが使用を開始できるようにすることは、大きな課題になる可能性があります。

私たちは、このタスクをより管理しやすくする多くのツールが存在する幸運な時代に生きています。 Postman のようなものを使用して、API 仕様を作成し、API 仕様をテストし、最終的に API をテストして、期待どおりに動作することを確認できます。 API のバックエンドを構築するには、Flask、Heroku などの多数のツールが必要です。または、ローコード ツールを選択して API を構築およびホストすることもできます。

この投稿では、API を構築するプロセスと、このプロセスをより効率的にする方法について説明します。

API 開発プロセス

API 開発は複雑で、回避する方法はありません。通常、API を設計し、コードを作成し、テストし、デバッグし、再度コードを作成し、さらにテストを行い、準備ができたらデプロイする必要があります。その後、終わりのないメンテナンスが続くようです。一般的な API 開発ライフ サイクルは次のようになります。

通常、プロセスの各ステップは別のツールまたはリソースによって実行されるため、API を実装するのはかなりの労力になる可能性があります。

たとえば、Postman を使用して API (Open API Specification) を設計し、flask のようなものを使用してコードを接続し、firebase またはデータベースに接続してデータを保存または取得することを選択できます。また、他の API やサービスに対して追加の REST 呼び出しを行う必要がある場合もあります。テストするには、Postman を再度使用できますが、コードとすべてのコネクタのデバッグが面倒になる可能性があります。デプロイには Heroku を選ぶかもしれませんが、それは API が必要とするものによって異なります。監視のために、監視システムを作成するか、Splunk などを使用できます。そして、API を維持する必要がある場合は、そのすべてに戻る必要があります。あなたは私が言おうとしていることを理解します。 API 開発は複雑です。

より良い方法を見つける

私は、API 開発ライフサイクルを簡素化し、API を設計から本番まで、わずかなツールで開発できる方法を求めていました。 Linx のようなローコード ツールのおかげで、これが可能になりました。以下の 3 つのツールのみを使用して、設計からデプロイまで API を作成することができました。

• Postman Postman を使用して API 仕様 (YAML ベース) を作成し、API をテストしました
• 使ったリンクスリンクスAPI を構築し、ロジックを実装し、デバッグし、最後にホストします。簡単に言うと、このガイド付きチュートリアルで API の構築を試すこともできます。
• SQL Server SQL Server は、API のデータを格納するために使用されました。事前に作成された AdventureWorks2019 データベースとそのデータを使用しました。

要件

ユーザー レコードのメンテナンスを行う単純な API を選択しました。 API には 5 つのメソッドがあります。

仕様の作成

要件に一致する YAML を使用して、Postman で簡単な API 仕様を作成しました。 Postman を使用すると、作成したものを確認し、視覚的に追加情報を提供できます。 Postman で API 定義を作成すると、テスト用にその API が既に設定されているという利点もあります。必要に応じて、この段階でテスト スクリプトを設定できます。

API の構築

API 定義ができたので、コードを作成できます。 Linx を使用すると、OpenAPI 3.0 仕様をインポートでき、指定された各メソッドのイベントが自動的に生成されます。 URI を指定してロジックを構築するだけで済みました。

データベース プラグインがインストールされると、各イベントのロジックの作成は比較的迅速に行われます。 Linx には、すべてのツールと同様に学習曲線がありますが、操作方法を理解するとペースが上がります。

API の各イベントにロジックと機能を追加しました。たとえば、GetAllUsers メソッドの場合、SQL データベースから読み取り、応答本文を介して結果を返す必要がありました。

API のテスト

API はすでに Postman にセットアップされているため、ロジックが実装された後、API がどのように動作するかをリアルタイムでテストするのは非常に簡単でした。以下の GIF は、作成した REST API を Linx デザイナーを使用してデバッグする方法と、デバッグ モードでテストする方法を示しています。

GIF

API が Linx でデバッグされているため、API を呼び出してデプロイ時の動作を確認できるようにホストされています。これにより、実際の結果をテストして取得できます。

もちろん、Postman にテスト スクリプトを追加して、テスト プロセスを自動化することもできます。これらのスクリプトにより、正しい応答が得られることが保証されます。

API のデプロイ

API の設計、開発、およびテストが完了したので、デプロイする必要があります。これは、従来の API 開発ではかなりの作業になる可能性があります。これは、デプロイ戦略を考え出し、どこで何をホストするかを決定し、監視とログ記録が確実に処理されるようにする必要があるためです。

私の展開は非常に簡単でした。 API を Linx Designer から Linx Server に直接デプロイしました。ソリューションが構築され、サーバーにプッシュされ、使用できるようになるまでに約 2 分かかりました。 Linx サーバーがこれを処理するため、API をホストすることの難しさは取り除かれます。また、監視とロギングも行います。

予期しないエラーが発生した場合にどうなるかを確認するために、間違った ID で GetUser メソッドを呼び出しました。サーバーはエラーをログに記録し、エラーが発生したことを赤で示します。

Postman から API を再度呼び出すことができました。サーバーは、API が呼び出されるたびに指示を出します。

確かに、API にセキュリティや認証の形式を追加していませんが、これらの設定は Linx デザイナーで利用できます。私が試した別のオプションは、API ドキュメントを swagger 形式で生成することでした。 /swagger をベース URI に追加することにより、ドキュメントが利用可能になり、API 自体でホストされるため、これは非常に価値があることが判明しました。これにより、必要に応じて API ドキュメントを簡単に配布できます。

まとめ

Linx と Postman を組み合わせると、API を設計、作成、文書化、およびホストできます。他のツールと同じように、慣れるまで少し時間がかかります。 Linx は標準的なプログラミング パラダイムと専門用語を使用しているため、C# などのプログラミング言語に精通していれば簡単に理解できます。 Linx を使用して API をデプロイおよびホストするときに、最も時間を節約できると感じています。監視とホスティングが自動的に行われるため、かなりの頭痛の種が解消されます。ロギングとモニタリングの粒度が十分でない場合は、Linx ソリューションに機能を追加できます。

Linx で API を構築してみたい場合は、自分で試すことができます

• 使用して最初に設計する(Postman を使用) または
• コードファースト（ビルドするだけ）