.svg)
私たちの意外と身近にある「API」ですが、その設計方法は時代の流れとともに変化してきました。
今回は、「REST」と呼ばれる設計思考に基づいて作られた「REST API」ついて解説していきます。
REST APIについて知りたい方や、APIをもっと詳しく知りたい方にぜひ読んでいただきたい記事になっています。ぜひ、最後までご覧ください！
REST APIについて解説していく前に、まずはAPIについて説明しておきます。
APIとは、Application Programming Interface（アプリケーション・プログラミング・インターフェース）の略称で、自社の開発したアプリケーションに、他社の開発したアプリケーションの機能を埋め込むための窓口を指します。
APIには、WebAPIやネイティブAPI、ライブラリAPIといった、目的・用途別に種類が分かれています。また、提供方法にもオープンなものとユーザー限定の大きく分けて2種類あり、そこからパブリックやクローズドなどに細かく分類されます。
また、一般的にAPIという場合は、パブリック型やビジネス型のWebAPIを指すことが多いです。
詳しくは、以前公開したブログ『意外と身近にある【API】を初心者にも分かりやすく解説』にて解説してますので、理解を深めたい方はぜひそちらもご覧ください。
REST APIとは、RESTというWeb設計思想に基づいて開発されたAPIのことを指し、HTTPプロトコルを最大限に活用できる設計モデルだと言われています。現在Web経由で公開される多くは、RESTに基づく実装になっていると言われています。
では、RESTとはどのような設計思想なのでしょうか？
RESTはRepresentational State Transfer（リプレゼンテーショナル・ステイト・トランスファー）の頭文字を取った略語です。単語を分解して意味を理解していきます。
・Representational … 具像的な（はっきりとした姿があること）
・State … 状態、ありさま
・Transfer … 移す、転送
これらの単語を繋げて意訳すると、「はっきりした状態でのやり取り」と理解することができます。
つまり、RESTはあらかじめ定義された形式でやり取りすることで、よりシンプルな設計を実現する思考と言えます。
ここでは、RESTの設計思考の誕生について、REST以前のAPIもあわせて振り返っていきます。WebAPIの主な設計の方法としては、RESTの他にRPCとSOAPがあり、年代順に解説していきます。
・RPC（Remote Procedure Call）
日本語で「遠隔手続き呼び出し」と訳されるRPCは、1960年代に分散システムの実現を目的に開発されました。
RPCはネットワークで接続され、互換性のある端末でれば、手元の端末でコマンドの入力・処理・実行、そしてプログラムの処理結果を受け取ることが可能でした。
・SOAP
1999年にMicrosoft社によって開発されたSOAPは、XML-RPCというRPCのうちXMLの送信で処理実行を要求するプロトコルの拡張です。通信内容の記述にXMLを使用し、サーバより必要なデータを取得します。高性能ですが、仕様の複雑さや、ニーズごとの機能追加でサービスが重くなってしまうため、現在ではほとんど使用されていません。
ちなみに、SOAPは元々Simple Object Access Protocolの略称として使われていましたが、W3C（World Wide Web Consortium：Web技術の国際標準規格を公開している団体）の宣言により固有名詞となりました。
・REST
REST APIは、HTTPを設計した中心人物であるロイ・フィールディング氏が2000年に発表した論文『Architectural Styles and the Design of Network-based Software Architectures』にて紹介されました。
2002年にebayがRESTful APIを開発し、続いてAmazonがRESTful APIをリリースしました。その際AmazonはSOAPのAPIもリリースし、利用率を調査したところ、REST APIの利用率が8割という結果が出ました。これにより、REST発表当初から起きていた、どちらを選択するかの論争は収束を迎え、REST APIが急速に普及していきました。
ロイ・フィールディング氏が提唱したRESTに則ったAPIを設計するにあたって、6つの要素があるとされています。場合によってはそれらを集約して、4原則と呼ぶこともあります。
【6つの要素】
以下のような要素を含むことで、RESTに則った、RESTfulなAPIを作ることができます。
・Uniform Interface（統一インターフェース）
データ形式はJSONもしくはXML、リクエストからレスポンスの処理はHTTPメソッドと、あらかじめ定義された方法を使ってやり取りをします。
・Stateless（ステートレス）
過去のセッション情報などは保持せず、やり取りが1回ごとに完結します。これにより、サーバは余分な情報の保管が不要になり、軽量化され、実装がしやすいだけでなく、拡張性を高めることができます。
・Client - Server（クライアント - サーバ）
RESTは、ほとんどのWebと同じようにクライアントとサーバは完全に分離する「クライアント・サーバアーキテクチャ」を前提とし、そのことを明文化しています。そのため、変更点の影響をお互いに受けることはありません。
・Cache（キャッシュ）
キャッシュとは、読み込んだ情報を一時的に保管し、次回の閲覧時に素早く読み込めるようにする方法です。REST APIはキャッシュ機能を活用することで、レスポンスに含まれるデータをキャッシュすることができ、これによりデータ通信量を抑え、ネットワークにかかる負荷を下げることができます。
・Layered System（階層システム）
システムをコンポーネント（構成要素）ごとの階層に分離するアーキテクチャです。システム設計では「レイヤードアーキテクチャ」という名前で知られています。お互い関係のないコンポーネントについて参照に制限を設けることで、シンプルな構造を保つことができます。
・Code - On - Demand（オンデマンドのコード）
プログラムコードをサーバからダウンロードし、クライアント側で実行する方法です。これにより、クライアントは新しい機能の追加が可能になります。
【4原則】
ここまで解説した6つの要素を集約して4原則と表現することがありますが、その場合は、上記の「統一インターフェース」と「ステートレス」に加え、以下の2つが入ります。
・アドレス可能性（Addressability）
全ての情報がURI（Uniformed Resource Identifier）という識別子を持ち、そのURIを通じて情報を表現できることです。Webの場合は、URL（Uniform Resource Locator）で与えられます。
・Connectivity（接続性）
サーバからの応答にはハイパーリンクを含めることができるため、円滑な情報連携が可能です。
上記6つの要素も踏まえて、REST APIのメリットとデメリットをまとめていきます。
【メリット】
REST APIを利用することで、開発者はシンプルな開発が可能です。データのやり取りを効率的に、システム間の連携・統合を容易に行うことができ、システム全体としての運用効率の向上が見込めます。また、必要な情報に迅速にアクセス可能なため、ユーザー体験向上へも貢献できます。
【デメリット】
ステートレスな特性は、過去の情報を保持する必要のある複雑なトランザクション（処理の1セット）を扱う場合には別で設計が必要になります。また、APIとシステムどちらかのバージョンが上がってしまうと互換性の問題が出てくる可能性があります。
ここまで、シンプルなWebの設計思考である「REST」、そしてそのRESTの設計思考をもとに作られた「REST API」について解説してきました。
意外と身近にあるAPIの設計方法は、Webの発展とともに変化し、よりシンプルに、より円滑な情報連携が行えるようになってきました。
JIITAKのプロダクト開発では、「テクノロジーの力で今日の挑戦を価値ある明日につなぐ」というミッションのもと、過去の開発経験をもとに、ヒアリングから丁寧にサポートさせて頂きます。過去にAPI連携にお悩みのあるプロダクト開発も行った実績もあります。
みなさまのアイデアをぜひ、JIITAKまでお聞かせください。
