統合の時代には、複数のプラットフォーム間でのデータ交換がこれまで以上に重要です。統合機能のないオンラインストアを考えてみましょう。商品リストの管理だけでなく、ユーザーアカウントの管理、メール購読の管理、支払い処理、発送などのシステムを開発しなければならないでしょう。これは拡張性がないため、これらの業務を他のプロバイダーに委託する方が効果的でしょう。
アプリケーション・プログラミング・インターフェース（API）は、ソフトウェアが互いに通信するために利用するものである。APIは、2つのプログラム間でデータを交換するための一貫したプロトコルを提供します。Web APIの助けを借りて、オンラインストアは配送ソフトウェア、クライアントアプリケーション、支払いアプリケーション、およびその他の必要な接続と通信することができます。
APIを作成する方法はさまざまですが、サービスにソフトウェア接続を追加する場合は、1つのユニークなテクニックを知っておくとよいでしょう。REST APIのWebサービスです。今回は、REST APIの例、REST APIとは何か、REST APIの仕組み、REST APIは何に使われるか、歴史、その要素などについて解説していきます。
REST APIとは一体何なのか？
Representational state transferまたはREST APIsのWebサービスは、アプリを組み込むための汎用的でポータブルな方法を提供するため、マイクロサービス・フレームワークでコンポーネントをリンクするための最も標準的なプラクティスです。RESTは、標準化された予測可能な方法で内部および外部の関係者と対話するために採用する、一般的なAPI設計です。
ウェブアプリケーションのユーザーは、頻繁にREST APIのウェブサービスを採用して、互いに通信しています。例えば、ソーシャルメディアプログラムにおけるアカウント詳細の取得やレビューなどです。REST APIsのブラウザは、ウェブの構文と見なすことができます。オンラインのお客様は、クラウドの利用が増えるにつれて、デジタル業務へのアクセスを提供・管理するためにWeb APIを活用するようになります。
顧客が分散したコンテキストで動的にデジタルウェブサービスに接続し、管理し、関与できるようにするウェブAPIを設計することは、賢明な判断である。Google、eBay、Facebook、Amazon、Twitter などの Web サイトでは、RESTful Web サービスが採用されています。クライアントアプリケーションは、RESTを使用してこれらのウェブサービスにアクセスできるようになりました。
RESTテクノロジーは、他の関連テクノロジーよりも支持されています。これは、RESTウェブサービスが消費する帯域幅が少ないため、効率的なオンライン活動に最適だからです。RESTfulなWebサービスは、JavaScriptやPythonなどのプログラミング言語を使って開発することもできます。
REST APIはどのように機能するのか？
REST APIの仕組みを知るには、いくつかの重要な用語を定義する必要があります。
クライアント
APIユーザーは、クライアントと呼ばれます。クライアントは、ウェブAPIにクエリーを送信して、データを取得したり、プログラムに変更を加えたりします。インターネットブラウザはクライアントであり、さまざまなウェブAPIと通信してページの内容を取得する。コンピュータは必要な情報を受け取り、それをディスプレイに表示する。
HTTPの代表的なメソッドは次のとおりです。
- GETリクエストは、要求されたデータや要求されたリソースを返すために使用します。
- 新しいリソースを作成するには、POST リクエストを使用します。
- 既存のリソースに変更を加えたり、更新を続けるには、PUT命令を使用します。
- DELETE命令を使用して、リソースを取り除く。
たとえば、YoutubeのAPIへのHTTPリクエストは、特定のビデオや投稿のためのGETリクエストリソースや、新しい写真を公開するためのPOSTリクエストとなることがあります。新しい投稿を公開するには、POSTリクエストメソッドを使用することができます。これに対応して、自動応答の実装と統合する顧客ウェブサービスプラットフォームは、カスタムハローを更新または削除するために PUT 命令を採用することができます。
Getリクエスト
- GETリクエストのキャッシュが可能です。ブラウザの履歴にはGETリクエストが含まれます。
- GETリクエストをブックマークに登録することができます。
- 重要な資料を扱うときには、決してGETリクエストを利用しないでください。
- GETリクエストには長さの制限があります。
- GETリクエストはデータクエリのみです。
POSTメソッド
POSTリクエストは、サーバーに情報を送信して、リソースを追加または更新するためのポストメソッドです。HTTPリクエストのリクエストボディには、サーバーサイドに公開されるデータが含まれます。
- POST リクエスト POST メソッドは、キャッシュに入ることはありません。
- POSTリクエストはブラウザの履歴に残りません。
- POST リクエストはブックマークできません
レスポンスボディ
レスポンスボディは、RESTful APIの重要な要素の1つである。リクエストされたデータは、レスポンスボディに含まれる。レスポンスボディには、出力および出力ロジックポートに関連するデータが含まれる場合があります。
リソース
ウェブAPIがユーザーに与えることのできるデータはすべてリソースです。例えば、個人、ページ、画像、発言はすべてFacebook APIにおけるリソースとみなされるかもしれません。リソース識別子は、各リソースに付与される特別な用語である。
ウェブサーバー
顧客のリクエストボディを受け取るプログラムは、消費者が要求するリソースを格納するウェブサーバーを使用する。サーバーは、データベースに保管されている情報への即時アクセスを顧客に提供することなく、APIを通じて顧客と通信することができる。ユーザーがRESTful Webサービスにアクセスしてリクエストボディを送信すると、サーバーはリソースの状態を正規化した描写をブラウザに送信する。
これは、サーバーが何らかの方法で正確なリソースをクライアントに送信するのではなく、その状態、つまり特定のタイムスタンプにおけるリソースの状況を反映することを意味する。理解しやすくするために、レスポンスは軽量なフォーマットで返される。
JSON（JavaScript Object Notation）は、人間にも機械にも読みやすく、Webアクセシビリティに優れているため、広く利用されている。JSONは主にWebアプリケーションやクライアントアプリケーションで、リクエストボディの送信に使われます。様々なコーディングに対応できる形式です。JSON以外のAPIデータ形式としては、XML、YAML、CSV、HTML、プレーンテキストがある。APIを利用するユーザーは、カスタムメディアタイプを利用することで、任意のデータ形式を選択することができる。
REST APIの歴史
多くのプログラマーは、APIを組み込むために、RESTの前にSOAPに取り組まなければならなかった。SOAPの構築、活用、デバッグは、悪名高く困難な作業でした。ありがたいことに、RESTはRoy Fielding氏の指揮の下、プログラマーチームによって開発され、API環境を永遠に変えることになった。
ここでは、REST APIの開発年表を紹介する。
REST以前
プログラマーは、SOAPを使ってWeb APIに接続するために、コンテンツ内にRPC（Remote Procedure Call）を含むXMLファイルを手書きで作成していた。その後、デザイナーは、指定されたエンドポイントにSOAPパッケージをPOSTしていた。
2000年当時
ロイ・フィールディング率いるプログラマーチームは、あらゆるサーバーと他のサーバーとの通信を可能にするフレームワークを開発することを選択した。そして、REST APIに必要な制限を定めた。このガイドラインは世界共通であるため、ソフトウェアの開発が容易になった。
2002年
eBayは2002年にRESTful APIを開発し、その恩恵を受ける可能性のあるあらゆるWebサイトにマーケットプレイスを開放した。このため、eコマースのもう一つの巨人であるAmazonがこれに興味を持ち、2002年にRESTful APIをリリースした。
2004年から2006年にかけて
2004年にFlickrのRESTfulウェブサービスがリリースされ、作家はウェブサイトやソーシャルメディアへの投稿に素早く写真を追加できるようになった。TwitterとFacebookは、相当数のプログラマーがウェブサイトをスキャンして「フランケンシュタイン」APIを作っていることに気づき、約2年後に両社ともAPIを公開した。
2006年～現在
RESTfulなウェブサービスがプログラマに広く受け入れられるようになり、プログラマはこれらのRESTfulなウェブサービスを利用して、アプリやサイトのパフォーマンスを向上させるようになった。AppMasterは連携を容易にし、APIの構築を容易にすることで、より迅速にAPIを構築することを可能にします。
REST APIは何に使われるのか？
RESTful Webサービスの主な利点の1つは、このRESTful APIをより効果的に使用できるように、非常に高い柔軟性を提供することです。以下では、REST APIがどのような用途に使用されるのか、いくつかのREST APIの例を紹介します。
クラウドベースのアプリケーション
その呼び出しがステートレスであるため、REST APIはクラウドアプリケーションで有利です。ステートレスなモジュールは、何か問題が発生しても、簡単に再インストールして、容量要件を満たすように成長させることができます。ローカルとインターネットベースのコンポーネントを組み合わせたソフトウェアプログラムは、クラウドアプリケーションです。このパラダイムでは，Web ブラウザーでアクセスできる遠くのサーバーと，進行中のインターネット Web サービスを使用して命令を実行する．
クラウドアプリケーションのホストは、従来はサードパーティのクラウドコンピューティングネットワークオペレーターが運営する遠隔地のコンピューターシステムでした。メール、文書共有・保管、注文入力、在庫管理、Microsoft Word、顧客管理（CRM）、情報収集、財務・会計などは、クラウド型アプリケーションで実行される仕事の一例である。
RESTアプリケーションプログラミングインターフェイス（API）は、外部の情報源やストレージリソースとの接続に使用できます。プログラマーは、REST APIを使用してクラウドアプリを小型化し、データを他のプログラムに転送して処理または計算を分析し、その結果をソフトウェアプログラムに返すことができます。テストされたAPIは、アクティブな均一性を強制し、生産を早め、実際の結果を出すことができます。
クラウドアプリケーションの代表的な例として、Google DocsやOffice 365があります。Google DocsやOffice 365に必要なのは、検索エンジンとインターネットのウェブサービスを実行できるコンピュータだけです。コンピュータネットワークは、ユーザーインターフェースと、情報の保存を含む操作を提供します。クラウドアプリケーションホストを利用すれば、多数の異なるクラウドアプリケーションを自社でホストすることができます。
クラウドサービス
APIを通じてリソースに接続するためにURLがどのように処理されるかを管理する必要があるため、REST APIはクラウドWebサービスにも有用です。RESTfulなウェブサービス・アーキテクチャは、クラウド・アプリケーションによって将来的に標準となる可能性が高い。プログラマーは、インターネットを使用してクラウドサービスに接続するためにRESTful Webサービスを使用します。開発者は、インターネットプロバイダーのAPIを使用するコードを作成し、必要な入力と変数を与え、その答えをチェックして、アクションが期待どおりに動作することを確認します。
エンドユーザーは、RESTful Webサービスのようなクラウドサービスを使って、クライアントアプリケーションや、計算インフラ、ストレージシステム、トラッキングシステムなど、クラウドWebサービスが提供するWebサービスにアクセスすることができます。APIは、アプリケーションの機能と操作、およびそれらを実行するために必要な仕様の概要を示しています。クライアントのプライバシーとセキュリティを維持するために、APIはしばしばRESTまたはSOAP（Simple Object Access Protocol）の相互運用性とOAuth 2.0のような許可メカニズムに依存する。
さまざまなウェブサービスは「クラウドサービス」と呼ばれ、企業や消費者の要望に応じてオンラインで利用できるようになっている。これらのウェブサービスは、ハードウェアやインフラを必要とせずに、ツールやアプリに素早く安価にアクセスできるように作成されています。多くの社員は、メールから文書連携まで、あらゆる場面でクラウドウェブサービスを利用しています。
Webの利用
RESTはクライアント側の機能に依存しないため、これらのWeb APIは、ユーザーのWebプロジェクト、iPhoneアプリ、IoTデバイス、Windows Mobileから取得することができる。特定のクライアント側のフレームワークに縛られることなく、ビジネスに応じたアーキテクチャを構築することができる。
REST APIの例
REST APIの例について説明します。下のリンクをクリックして、オープントリビアデータベースに任意の知能の問い合わせをしてみてください。このようなRESTfulなWebサービスは、公開されたWeb APIを提供するために使用されました。あなたのコンピュータには、孤独なクイズの質問とその回答がJSON形式で表示されます。
urlのような任意のHTTPブラウザーを使って、次のような問い合わせを行い、レスポンスボディで応答を受け取ることができます: https://opentdb.com/api.php?amount=1&category=18
WebサービスのXMLファイルのレスポンスボディには、従業員のすべての情報が含まれます。
広く使われているプログラミング方言や開発者用ツールには、JavaScript、Node.js、DenoのretrieveやPHPのfile get contents()などのHTTPクライアントライブラリが用意されています。JSONの回答は、HTMLや他のスタイルで表示される前に機械で読み取ることができるため、読んで利用することができる。
RestとRESTのAPI
時が経つにつれて、多くのデータ転送方法が開発されてきました。CORBA、SOAP、XML-RPCのような選択肢に出会ったことがあるかもしれません。その多くは、厳格なメッセージガイドラインを策定しています。Roy Fieldingは2000年にRESTの概要を初めて説明したが、これは他のものよりもずっと分かりやすい。
これは、規範というよりも、RESTfulなWebサービスに対する提案と制限をまとめたものである。これらは以下のようなアーキテクチャ上の制約から構成されている。
クライアント・サーバ間パーティション
RESTアーキテクチャの下では、クライアントとWebサーバーは一方向にしか通信できない。クライアントがドメインコントローラーにリクエストを出し、コントローラーまたはサーバーがそのリクエストに応答する。ウェブサーバーはリクエストを送信できず、顧客は反応できない。コンシューマーがすべての接続を開始する。
RESTfulなウェブサービスは、顧客とサーバーの間の相互作用を緩和することで、顧客とサーバーを隔離します。クライアントコンピュータは、他のホスティングに影響を与える心配なく開発でき、サーバーのマテリアルは、顧客に無意識のうちに影響を与えることなく変更することができます。
統一されたインターフェース
この戦略によれば、すべての問い合わせや反応は、標準的なプロウェブの手順やメッセージのスタイルに従わなければならない。アプリやサーバーは様々なプログラミング言語で開発されており、メディエーターとの連携はうまくいきません。統一されたインターフェースは、どの顧客もどのREST APIと対話するために使用することができる方言です。
アプリケーション間のリクエストとリアクションを正規化された相互作用で翻訳することが、初めて可能になるのです。わずかな違いでも混ざり合って情報が失われ、ウェブAPIが変更されると、ソリューションはリクエスト手順をアップグレードしなければならなくなります。一貫性のあるインターフェースは、このような問題を解決してくれます。
https://www.googleapis.com/youtube/v3/channels?part=contentDetailsにアクセスする
すべてのRESTクライアントアプリケーションと同様に、この提案も2つのデータを含んでいます。HTTPの技法はGETです。これは、クライアントがリソースに対して行いたいアクションを記述します。ユーザーは、4つの基本的なHTTP手法を行うことができます。
HTTP（Hyper-Text Transfer Protocol）は、ほとんどのREST APIの世界共通言語である。HTTPは、RESTを意識して設計されたものではありません。さらに、RESTはこのデータ転送をREST対応アプリの基準として受け入れていました。REST APIでHTTPを使用するために、クライアントは、あなたが知っているようなフォーマットでリクエストを送信します。例えば、YouTube APIへのビデオ信号の問い合わせは、このようなものです。
- リソースを取得するにはGETコマンドを使用します。
- 新しいリソースを作成するには、POST命令を使用します。
- PUT命令を使用して、既存のリソースに変更を加えたり、更新を続けたりする
- リソースを削除するには、DELETEリクエストを使用します。
HTTP メソッドは、特定のリソースに関して実行される意図されたアクションを指定します。HTTP メソッドは HTTB 動詞としても知られています。
URL は HTTP です。
意図するリソースを識別する統一リソース識別子、または URI が URL に含まれます。このシナリオでは、URLはRESTful APIがサービスユーザーと接触する場所であるため、エンドポイントでもある。
クエリ文字列。URLには、クエリ文字列が含まれます。クエリ文字列は、与えられた値であるパラメータを定義するために使用される。
クエリを受信して確認した後、Webサーバーは対象のリソースのデータを返します。通常、データはJSON（JavaScript Object Notation）と呼ばれる構造で返される。JSONは、リソースのすべての構成要素を、Humansが簡単に読めるポータブルな形式で提示します。
ユニフォームインターフェイスの原則
統一インターフェースは、以下のパラメータに従わなければなりません。
HATEOAS: アプリケーション状態のエンジンとしてのハイパーメディア
ハイパーメディアはRESTfulなウェブサービスを支えるエンジンです。これは、顧客がプロバイダの答えを認識するために理解したいのは、ハイパーメディアだけであることを示しています。
- クライアントアプリケーションの最初のURIのみがクライアントに提供されなければならない。クライアントアプリケーションは、ハイパーリンクを使用して他のすべての資料とアクティビティを継続的に駆動する必要があります。
- RESTfulウェブサービスは、他のAPIと異なり、入力問い合わせ言語（IDL）を必要としない。
メディアタイプは、表現のデータ形式の名前です。メディアタイプは、描写がどのように扱われるべきかを概説する定義を特定する。RESTを使用するWeb APIは、ハイパーテキストのように見える。アドレス指定可能なすべてのデータ項目は、直接（リンクやIDプロパティなど）または暗黙（メディアタイプ記述構造から得られるなど）のいずれかで、位置を負います。
自己記述的なメッセージ
クライアント側とサーバー側との間の各通信は、その通信を実行するために十分なデータを提供する必要がある。従って、クライアント側からサーバー側へのリクエストは、アクセスしようとしているリソースとその具体的な目的を特定する必要がある。
さらに、リソースの描写は自己記述的でなければならない。ユーザーは、リソースが人であるか機器であるかを意識する必要はない。その代わり、ヘルプに接続されたメディアタイプに従って応答する必要がある。
したがって、議論の余地なく、多くのユニークなメディアタイプ、多くの場合、リソースごとに1つのメディアタイプを開発することになる。あらゆる形式のメディアは、標準的な制作パラダイムを指定します。たとえば、HTMLはハイパーテキストをどのように表示するか、ブラウザが各コンポーネントをどのように扱うかを定義している。リソースの識別
顧客とサーバー間の後方通信で参照されるリソースは、描写を使用して認識可能でなければならない。URI（Uniform Resource Identifier）方式にこだわることで、これが可能になった。つまり、サーバーからお客様への通信には、サーバーのストレージにある実際のファイルではなく、HTML版のドキュメントと何らかの情報が含まれる可能性があるのです。
HTML版はURIのパターンに従っているので、消費者は容易に理解することができる。顧客は、リソースが最終的にどのように表示されるべきかの描写をサーバーに与えることによって、リソースを修正しなければならない。これにより、ユーザーはリソースを構築、取得、修正、削除できるようになる。顧客がデータを変更するのに必要な権限を持っている場合、サーバーはクエリーを満たす必要があります。
ステートレス
RESTful API では、クライアントのリクエストはすべて一時的でなければなりません。その結果、各クエリーとレスポンスボディには、契約を締結するために必要なすべてのデータが含まれ、各接続が自律的に行われるようになる。サーバーは以前のHTTPリクエストを追跡せず、クライアントによる各リクエストをまったく新しいクエリとして扱います。
サーバーは履歴データを取得するために余分なタスクを実行する必要がないため、ステートレス・トランスポートはサーバーに必要なストレージ量を大幅に削減し、応答が受け入れられる可能性が高くなる。これは、これらのインタラクションのスケーラビリティを保証します。プログラマは、ソフトウェアが拡張してHTTPリクエストを行う際に、より多くのストレージを使用したり、サーバーに負担をかけることを心配する必要がありません。
レイヤー化
ここまで、Web API のクエリを単純なクライアントとサーバーのやり取りと定義してきたが、これは少し単純化しすぎである。この二つの組織の間には、もっと多くのサーバーが存在することが多い。これらのプラットフォーム（レイヤー）は、トラフィックを管理・分散し、保護を追加し、その他様々な重要なタスクを実行するために配置されています。
この概念によれば、ユーザーとターゲットサーバーの間で送られるメッセージは、間に存在するレイヤーに関係なく、同じように構造化され、処理されなければならない。余計なレイヤーは、顧客とのやり取りで構わないはずです。このルールを守っているプログラマーは、基本的なリクエストとレスポンスのプロセスに影響を与えることなく、サーバーシステムを変更することができます。
キャッシュ可能
キャッシュは、お客様がウェブサイトを閲覧する際に、お客様のマシンにコンテンツが保存されている場合に発生します。キャッシュされたものは、ユーザーが後でそのサイトを訪れたときにサーバーから再びダウンロードされるのではなく、内部メモリーから速やかに読み込まれる。ほとんどのビッグサイトでは、サーバースペースと帯域幅を節約しながらページの負荷を軽減するためにキャッシュを使用しています。
REST APIを開発する際には、データキャッシングが考慮されます。サーバーが顧客に返すレスポンスには、与えられたリソースが保存可能かどうか、またどの程度の期間保存可能かを記述する必要があります。
需要に応じたコード
最後のRESTの信条は不要である。要求された場合、APIのレスポンスはクライアントが使用するためのソフトウェアコードを含むことができる。このため、顧客はそのバックエンドでクライアントアプリケーションやプログラムを実行することができる。
APIは、この一連のガイドラインに準拠していれば、RESTful APIとみなされる。しかし、このガイドラインは、プログラマーにRESTful APIの機能を変更する多くの自由を与えている。REST APIは、同じくWeb APIの代表的な手法であるSimple Object Access Protocol（SOAP）とは異なり、より柔軟性が高いのが特徴です。
エンドポイントのコンセンサス
これらのエンドポイントを考慮に入れてください。
- /user/123</p> <p
- /user/id/123s
- /user/123\s/user/id/123\s
- /user/?id=123
いずれも、クライアント123がデータを取得するための正当な方法である。もっと複雑な手順があると、可能性は大きくなる。例えば、51番目の項目から逆順に、「A」から始まる名字で、この会社で働いている人を10人表示させる。
結局のところ、URLの構造はどうでもよくて、RESTful API全体の統一が重要なのです。多くのプログラマがいる巨大なソフトウェアシステムでは、それは簡単なことではありません。RESTful APIの修正は避けられませんが、エンドポイントURLを拒否することは絶対に避けなければなりません。そうすると、それに依存しているアプリが動かなくなるからです。
REST APIのバージョニング
APIをバージョン管理することは、非互換性を防ぐためによく行われることです。例として、/2.0/user/123は/user/123に取って代わります。古いエンドポイントと新しいエンドポイントは、どちらも機能し続けることができます。その結果、過去の重要なAPIを維持する必要性に迫られます。最終的に旧バージョンをリタイアさせることは可能だが、その手順については慎重に考える必要がある。
REST APIの認証
照会APIを使えば、どの端末でも認証なしでquipをダウンロードすることができる。個人情報を読み取るAPIや、問い合わせの編集・削除が可能なAPIには対応していない。RESTful Webサービスと同一ドメイン内のクライアント側プログラムは、HTTPリクエストと同様にCookieを送受信します。(なお、Fetch()については、それ以前のサイトでは特権再起動オプションが指定されている必要があります)APIクエリーを検証することで、ユーザーがサインインしているか、必要な権限を持っているかを確認することができます。
HTTPの基本認証。サードパーティプログラムは、異なる承認ソリューションを使用する必要があります。一般的な認証方法には、以下のような一次認証があります。
- HTTPです。HTTP Approvalヘッダーの一部として、base64エンコードされたユーザー名：パスワード文字列がクエリフィールドに与えられます。
- APIキー。RESTful API キーを提供することで、サードパーティアプリケーションが API を利用できるようになります（特別な許可や単一サイトへの制限がある場合があります）。各メッセージは、クエリ文字列またはHTTPヘッダーのいずれかにキーを含んでいます。(クエリーストリングは、URLの構成要素です）。
- OAuth：リクエストを行う前に、顧客IDと顧客秘密がOAuthサーバーに送信され、クレデンシャルを取得する。有効期限が切れるまで、OAuthのIDは各APIリクエストと一緒に送信される。
- JSONのインターネットトークン（JWT）。クエリヘッダとレスポンスヘッダで、デジタル署名されたユーザークレデンシャルを安全に伝達する。JWTを使用すると、サーバーはアクセス権を暗号化できるため、データベースへの問い合わせや他の認証メカニズムを使用する必要がなくなります。
APIがどのように認証されるかは、使用シナリオに影響されます。
- サードパーティーのプログラムは、同じ権限と特権を持つ他のログインしたクライアントと同様に扱われることがあります。例えば、地図APIは、リクエストしたプログラムに2つのスポット間の指示を提供するかもしれない。この場合、APIはそのプログラムが正当なユーザーであることを確認しなければならないが、クライアントの認証情報を確認する必要はない。
- また、サードパーティーのプログラムが、メールの内容など、特定のユーザーの個人情報を要求する場合もあります。REST APIはクライアントとその権限を認識する必要がありますが、呼び出し側のプログラムについては考慮する必要はありません。
REST APIのセキュリティ
RESTful Web サービスは、ソフトウェアとの対話と影響を与える方法をさらに増やします。たとえあなたのホストが高度なハッキングの目的でなくても、行儀の悪いユーザーが1秒間に何百ものリクエストを送信し、それを崩壊させる可能性があります。この記事では、セキュリティについては説明しませんが、標準的な最良の手順が含まれています。
HTTPS を使用する
強力な認証メカニズムを採用する
CORS を使用して、顧客の通話を特定の領域に制限することができる。
必要な機能を提供する - つまり、しないこと。
エンドポイントのURLと本文をすべて確認する。
クライアントサイドのJavaScriptでAPIバウチャーを対象としないことで、未確認のセクターやIPアドレスからのリンクをブロックする。
異常に大きなパケットをブロックする。
同一IPアドレスやAPIクレデンシャルからのリクエストは1分間にN回のクエリに制限するレート制限を考えてみよう。
適切なHTTPステータスコードでの応答、キャッシュヘッダーのログクエリ、調査の不成功
複数回のリクエスト、不要なデータ
RESTfulなWebサービスの展開には限界があります。レスポンスに要求した以上の情報が含まれていたり、すべての情報を取得するために複数のリクエストが必要だったりする可能性があります。ユーザーにクリエイターと書籍の情報へのアクセスを提供するRESTful Webサービスについて考えてみましょう。クライアントは、次のようなことが考えられます。
- クライアントが、購入順に並べた最初の10冊の本の情報を要求する（トップセラーが最初）。本のコレクションと各作家のIDが答えに含まれます。
各作家の情報を取得するために、最大10個の/author/idクエリを構築する。
N個のAPIクエリは、親クエリに対する各レスポンスに対して生成される必要があり、"N+1問題 "として特徴付けられる。
これが頻繁に使用される状況であれば、RESTful Web サービスは、名前、性別、国籍、経歴など、制作したすべての本のすべての作家情報を含むように修正されるかもしれません。そうするとレスポンスの負担が大きくなりますが、過去の著書に関する情報をさらに提供することも可能です。APIはchであってもよい書き手情報を任意にするために変更しました。Author details=fullは、不必要に大きな解答を防ぐためです。APIデザイナーがサポートしなければならないオプションの数が多すぎて、圧倒されてしまうかもしれない。
まとめ
これで、REST API、REST API の動作方法、REST API の例、REST API の使用目的、アーキテクチャーの制約、およびこのチュートリアルで取り上げたその他のトピックについて、十分に理解することができました。プログラマーはAPIについて学ぶことを難しく感じたり、怖がったりするかもしれませんが、ノーコード・プラットフォームAppMasterは、新たにアクセス可能なREST APIライブラリを作成し、様々なREST APIについて認識を深め、さらなる専門的な開発をサポートすることができるようになりました。
AppMasterでは、APIのアクセシビリティとユーザビリティを高めるよう心がけています。APIソフトウェアについて学び、実験し、キャリアや個人生活でAPIソフトウェアを使用することの利点を実感していただきたいと考えています。より良いWeb APIをより早く設計できるよう、AppMasterはコラボレーションを改善し、APIライフサイクルの各段階を自動化します。これからもREST APIを作成し、進化させ、理解を深めてください。
