rest api tutorial rest api architecture
このチュートリアルでは、REST API、Webサービス、REST APIのアーキテクチャ、REST API制約、およびPOSTMANを使用してAPIをテストする方法について学習します。
前提条件: Webサービスの基本的な知識。
小切手 ここに Webサービスを明確に理解するため。
学習内容:
REST APIとは何ですか?
APIは単なるインターフェースであり、ソフトウェアコンポーネントが相互に通信するために使用します。サービスは、明確に定義され、自己完結型であり、他のサービスに依存しない機能です。
WebサービスはAPIの一種であり、ほとんどすべてがHTTPを介して動作します。 Web APIがRESTアーキテクチャを使用して開発される場合、それはREST WebAPIと呼ばれます。
現在のところ、Webサービスには2つのタイプがあります。
- 石鹸
- 残り
SOAPとRESTの違い
石鹸 | 残り |
---|---|
リクエスト本文でデータを送信するには、XML形式のみを使用できます | リクエストを送信するために、XML、JSONなどの形式を使用できます。 |
それはプロトコルです | これはアーキテクチャスタイルであり、プロトコルに依存しません。RESTはSOAPWebサービスを使用できます。 |
Simple Object AccessProtocolの略です | これは、Representational StateTransferの略です |
サービスインターフェイスを使用してビジネスロジックを公開します。 | URIを使用してビジネスロジックを公開します。 |
SOAPには、従うべき厳格な基準があります。 | RESTが従うべき、言及されたそのような厳密な基準はありません。ただし、ユーザーは、RESTを使用してWebサービスを開発する際に、いくつかの標準に従うことができます。 |
より多くの帯域幅が必要です。 | 軽量です。 |
独自のセキュリティを定義できます。 | RESTは、トランスポートからセキュリティ対策を継承します。 |
最良の例はグーグル、アマゾンです | 最良の例はYAHOO、LINKEDIN、AMAZONです |
SOAPはHTTP、SMTPなどのプロトコルを使用します | RESTはHTTPのみに依存しています。 |
メッセージや操作などをバインドするためのルールはWSDLで記述されています | RESTは、Webサービスによって提供される機能を記述するためにWADL形式に従います |
標準化されています。 | RESTサービスは標準化されていません。 |
既存のルール、バインディングなどのため、より多くの学習時間が必要です。 | シンプルなため、学習にかかる時間が短くなります。 |
SOAPよりもRESTを選択する理由
以下のポイントは、SOAPではなくRESTを選択する理由を説明しています。
- WebAPIの開発とテストに非常に適しています。
- RESTはより少ない帯域幅を必要とします。
- RESTベースのWebAPIにはAJAXを使用できます。
- 必要な解析オーバーヘッドが少なくなります。
- JSONによって作成されたペイロードサイズはサイズが小さくなります。
Web上で利用できるクライアント/ツールは多数あり、RESTfulWebサービスを利用できます。
彼らです:
- 郵便配達員
- AdvancedRestクライアント
- DHCRestクライアント
- リクエスター
- 不眠症
- 主張可能
- ポスター
なぜ郵便配達員?
- 使用可能なすべてのオプションが表示されます。
- Postmanには追加機能(ランナーとして知られています)があります。
- ユーザーフレンドリーなUIと使いやすい。
- より大きなコミュニティグループ/メンバー。
RESTAPIアーキテクチャ
これは主に、ソフトウェアアーキテクチャスタイルのWebのアーキテクチャです。分散型ハイパーメディアシステム用です。 RESTful APIは、RFC2616プロトコルで定義されたHTTP方法論を直接利用します。
いくつかの定義
火 Application ProgrammingInterfaceの略です。これは、アプリケーションソフトウェアを構築するためのサブルーチン定義、プロトコル、およびツールのセットです。
ウェブサービス データ/組み込みメソッドを含むいくつかのプログラムコードです。これらは、ユーザーやサードパーティアプリケーションなどと通信するために、インターネットを介して組織によって展開されます。メッセージを通信するために、ほとんどの場合XMLがメッセージングシステムとして使用されます。 XMLは、ユーザーとアプリケーション間のすべての通信を単純にエンコードします。
HTTP ワールドワイドウェブで使用されるハイパーテキスト転送プロトコルを意味します。メッセージのフォーマットと送信の方法、およびさまざまなコマンドに応答してWebサーバーとブラウザーが実行するアクションを定義します。
建築様式、 これらは、構造を作成し、それを独自のものにするために使用される機能によって特徴付けられます。スタイルには、レイヤードインターフェイスとユニフォームインターフェイスの2つのタイプがあります。
嫌い :Uniform ResourceIdentifierとも呼ばれます。リソース(テキストドキュメント、画像ファイルなど)を識別します。
URL: ユニフォームリソースロケーターとも呼ばれます。これはURIのサブセットであり、ネットワークの場所が含まれています。
URN :Uniform Resource Nameとも呼ばれ、URIのサブセットであり、特定のスペース内に名前が含まれていますが、場所は含まれていません。
例えば、
http://elearning.com/amazon/restapi.html#books
ここで、上記の例では
嫌い :http://elearning.com/amazon/restapi.html#posts
URL :http://elearning.com/amazon/restapi.html
URN :elearning.com/amazon/restapi.html#posts
例と構文を含むUNIXコマンド
したがって、URLは、リソースを識別するURIであり、リソースにアクセスする方法を記述することによってリソースを見つける手段も提供します。
したがって、すべてのURLをURIにすることができますが、その逆は当てはまりません。
RESTfulサービスは、Uniform Resource Locator(URL)を介して公開されます。これは、リソースのIDを、受け入れまたは返されるものから分離する論理名です。
サンプルRESTアーキテクチャ:
RESTAPIの制約
APIインターフェースは、以下の制約を満たす場合、RESTfulであると言われます。
- 統一されたインターフェース: つまり、使用しているクライアントに関係なく、RESTサービスの実装と使用の基本的な概念は変わりません。開発されたすべてのRESTAPIは、開発に対して共通のアプローチを持つ必要があります。
- ステートレス: これは、保存されるセッションがないことを意味します。そのため、サーバーはクライアントから送信されたHTTPリクエストを保存しません。したがって、サーバーの場合、すべてのHTTP要求は新しい要求です。リクエストが何回行われたか、または顧客が一意であるかどうかに関係なく。
- キャッシュ可能: キャッシュとは、サーバーではなくキャッシュからデータと応答にアクセスする頻度を意味します。キャッシュの概念は、クライアント要求の送信中に適用できます。そのため、パフォーマンスの向上はクライアント側で行われます。
- クライアントサーバー: サーバーとクライアントは、実装に関して互いに独立しています。クライアントは、認証ありまたは認証なしでリクエストURIを送信するだけで済みます。次に、サーバーは残りのステップ、つまり応答を実行します。
- 階層化システム: クライアントは、リクエストのみをリソースURIとしてサーバーに送信できます。ただし、リクエストがサーバーに送信される前に、階層化されたシステムアーキテクチャを提供するRESTAPIが存在します。つまり、APIを1つのサーバーにデプロイし、データを別のサーバーにデプロイし、認証を別のサーバーにデプロイすることができます。
- コードオンデマンド(オプション): クライアントは、応答以上のものを必要とする場合があります。 REST APIを使用すると、実行可能コードを応答として送信できます(この実行可能コードはウィジェットまたは任意のコントロールにすることができます)。ただし、この機能を有効化/実装したかどうかは完全にオプションです。
Rest APIに関連するいくつかの用語:
終点 :Webリクエストを受け入れるURLへの参照です。 Webサービスは、エンドポイント参照を使用してアドレス指定できます。
例えば、 Http:// {Domain_URL} //librarygr/libraries.xml
リソース :エンドポイントのサブセットです。通常、エンドポイントは、Webサービスを通じて消費できるいくつかのオブジェクトを公開します。リソースは具体的には、エンドポイントURI上のオブジェクトのその部分です。
例えば、 Http:// {Domain_URL} // api / pg_library / ornithology / swan
ペイロード :ペイロードは、POSTまたはPUT操作の実行中に送信される情報です。これらは、HTTPリクエストの本文で指定されている情報です。
ペイロードはJSON形式で送信されます。 例えば、
{ Id: 1, name:'sam', phones:({title:'mobile',number:9898989899}, {title:'home',number:8888888888}) }
パラメーター :
パラメータは2つの方法で渡すことができます。
クエリパラメータ : URLのクエリ文字列(?の後の部分)のキーと値のペアにアクセスするのに便利です
最良の例
http://jsonplaceholder.typicode.com/posts/?id=3
パスパラメータ: URLの一部をパラメータとして一致させると便利です。次の方法でパスパラメータとして情報を送信できます:Form-data、x-www-form-urlencoded、raw、binary。
最良の例:
https://api.github.com/gists/49b05378bb8920d5b4ec54efc27103e2/comments
スタックc ++の実装
POSTMANとは何ですか?
POSTMANはRESTクライアントであり、Chromeブラウザに付属する単なるアプリです。これは、API呼び出しのテストを容易にすることを開発者に念頭に置いて開発されています。 APIリクエストを送信してAPIレスポンスを読み取るための独自のGUIがあります。
REST APIテストは、手動と自動の両方で実行できます。
次のセクションでは、POSTMANクライアントを使用してWebAPIを手動でテストする方法を学習します。
PostmanでAPIをテストする方法は?
インストール
アクセスする必要があります Chromeウェブストア 。 ChromeブラウザでPostmanを検索します。クリック ここに Chromeボタンに追加します。
正常にインストールされると、Chromeアプリの下にPOSTMANが表示されます。 PostmanアイコンをクリックするだけでPOSTMANが開きます。初めての起動には時間がかかります。
使用方法を理解するには、次のURLを参照してください POSTMAN ツールとして。
前提条件: Web経由で展開されるサービスにアクセスするには、インターネット接続が必要です。ローカルにデプロイされたサービスにアクセスする場合は、POSTMANを介してテストを実行しているユーザーに十分な権限と特権が付与されていることを確認してください。
ダミーリソースURI: このチュートリアルでは、実際のURIの代わりにダミーのURIを使用します。必要に応じて応答が返されますが、サーバーに変更を加えることはできません。
http://jsonplaceholder.typicode.com
ナビゲーション手順 :
#1) POSTMANアプリを起動すると、デフォルトでリクエストページが表示されます。
#二) ドロップダウンをクリックすると、API呼び出しのリストが表示されます。ドロップダウンからオプションのいずれかを選択することで、サーバーへのAPI呼び出しをリクエストできます。
#3) POSTMANの右上隅にある(環境変数)ボタンをクリックします。テストする特定の環境を設定します。将来の実行のために保存できます。
#4) 保存された環境には、(環境)ドロップダウンからアクセスできます。
#5) 次に、指定されたボックスにリソースURIを設定する必要があります。
#6) (リソースURI)フィールドの横にある(パラメータ)ボタンをクリックして、クエリパラメータを指定します
# 7) (承認)タブをクリックし、ドロップダウンから(承認の種類)を選択して、必要な承認を設定するか、単に承認なしのままにすることができます。
#8) (ヘッダー)タブをクリックして、コンテンツタイプなどの必要なヘッダーを設定します
#9) (本文)タブをクリックし、フォームデータラジオボタンを選択します。リクエストURLと一緒に送信する必要がある必須の本文パラメータを指定します
#10) (本文)タブをクリックし、(x-www-form-urlencoded)ラジオボタンを選択します。リクエストURLとともに、エンコードとして送信する必要のある必須の本文パラメーターを指定します
#十一) (本文)タブをクリックし、(未加工)ラジオボタンを選択します。リクエストURLと一緒に送信する必要がある必須の本文パラメータを指定します。これは実際のJSON形式です
例を含むJava8の新機能
#12) (本文)タブをクリックし、(バイナリ)ラジオボタンを選択します。リクエストURLと一緒に送信する必要のある必須の本文パラメータ(通常はファイルとして)を指定します。
#13) 上記のようにすべての詳細を構成したら、リクエストを「送信」できます。また、送信リクエストをrequest.jsonとして保存することもできます(リクエストの名前を変更する場合があります)。
#14) 左側のパネルの(履歴)タブに、行われたリクエストのリストが表示されます。
#15) また、リクエストに関連するすべての詳細(URI、承認、パラメーター、本文など)を既存のコレクションまたは新しいコレクションに保存できます。リクエストがコレクションに追加されると、それをエクスポート(共有)したり、既存のコレクションをインポートしたりすることもできます。
コレクションは、リンクとして、または単純に生成されたコードによってチームライブラリとして共有できます。コレクションスイート全体をいつでも実行できます。
コレクションのURLをWebに公開して、公開されたURLにアクセスするすべての人がコレクションにアクセスし、WebAPIによって提供されるサービスを利用できるようにすることもできます。
POSTMANにログインする機能があります。これにより、履歴、コレクション、環境データ、ローカルストレージを保存して、POSTMANにログインした後、いつでもどこからでも保存してアクセスできるようになります。
ランナー
これは、Collectionsフォルダーにあるリソースを実行するために使用されます。
結論
ほとんどの企業は、Webサービスの開発/実装にRESTアーキテクチャスタイルを採用しています。これは、シンプルでユーザーフレンドリーなインターフェイスであり、プロジェクトの既存/新規メンバーのトレーニングが少なくて済むためです。組織は、既存のWebサービスとともにRESTを検討しています。
= >>もお読みください FlaskAPIチュートリアル
このRESTAPIシリーズの次のチュートリアルでは、さまざまなタイプの応答コード、RESTリクエストのタイプなどについて説明します。