🍣

【初学者的まとめ】REST APIとは

3 min read

REST APIとは

RESTというアーキテクチャに準拠したAPIのこと
RESTとはクライアント/サーバ(リクエストとレスポンス)にいくつかの制約を課したもの
APIとは機能やデータを外部から呼び出して利用できるようにする規約のこと
URIで一意に示したリソースに対して、HTTPメソッド(GET/POST/PUT/DELETE)を使ってデータ(JSON、XML等)のやりとりを行う

以下、『Webを支える技術』よりRESTについての記述を簡易的にまとめた

RESTとはWebのアーキテクチャスタイルである

ネットワークシステムのアーキテクチャスタイル

  • 最も有名なネットワークシステムのアーキテクチャスタイルはクライアント/サーバ
  • Webはクライアント/サーバ
    RESTはクライアント/サーバから派生したスタイル
  • 素のクライアント/サーバにいくつかの制約を加えたもの
    実装から抽象度を一つ上げたのがアーキテクチャ
    アーキテクチャから抽象度を一つあげたのがアーキテクチャスタイル
抽象化レベル Webでの例
アーキテクチャスタイル REST
アーキテクチャ ブラウザ、サーバ、プロキシ、HTTP、URI、HTML
実装 Apache、Firefox、Internet Explorer

リソースの概念

Web上に存在する、名前を持ったありとあらゆる情報

  • リソースの名前は、あるリソースをほかのリソースと区別するためのもの
  • リソースはURIで一意の名前を持ち、プログラムがリソースの表現する情報にアクセス可能になっている
  • URIはアドレス可能性(Addressability)を持っている
    アドレス可能な状態 = 名前がついており適切な手段でアクセスできる状態

RESTは複数のアーキテクチャスタイルから構築されている

クライアント/サーバにほかのアーキテクチャスタイルを追加して制約を課していく

  • クライアント/サーバ
    クライアントがサーバにリクエストを送り、サーバはそれに対してレスポンスを返す
    • 利点:単一のコンピュータで全てを処理するのではなく、クライアントとサーバで分離して処理できる
  • ステートレスサーバ(クライアント/ステートレスサーバ)
    クライアントのアプリケーション状態をサーバで管理しない
    • 利点:サーバ側の実装を簡略化できる
    • 現実にはステートレスでないWebサービスやWeb APIは存在する
      例:Cookieによるセッション管理は、RESTの観点では間違ったHTTPの拡張である(ステートフル)
  • キャッシュ(クライアント/キャッシュ/ステートレスサーバ)
    リソースの鮮度に基づき、一度取得したリソースをクライアント側で使い回す
    • 利点:サーバとクライアントの間の通信を減らすことでネットワーク帯域の利用や処理時間を縮小し、効率的に処理できる
  • 統一インタフェース(統一/クライアント/キャッシュ/ステートレスサーバ)
    URIで指し示したリソースに対する操作を、統一した限定的なインタフェースで行う
    • 利点:
      • インタフェースの柔軟性に制限を与えることで全体のアーキテクチャがシンプルになる
      • インタフェースを統一することでクライアントとサーバの実装の独立性が向上する
        • 例:HTTP 1.1ではGET・POSTなど8個のメソッドだけが定義されている
  • 階層化システム(統一/階層化/クライアント/キャッシュ/ステートレスサーバ)
    統一インタフェースはシステム全体を階層化しやすい
    システムを複数階層に分割することでインタフェースの違うシステムにも接続できるようになる
    • 例:
      • サーバとクライアントの間にロードバランサを設置して負荷分散
      • プロキシを設置してアクセスを制限
      • Web/アプリケーション/DB
    • 利点:コンポーネントに役割を決めて独立させる(カプセル化など)ことで、進化と再利用が促進できる
    • 欠点:データ処理にオーバヘッド発生(ユーザから見ると応答が悪く見える)、キャッシュを利用すると改善が見込める
  • コードオンデマンド(統一/階層化/コードオンデマンド/クライアント/キャッシュ/ステートレスサーバ)
    プログラムコードをサーバからダウンロードし、クライアント側でそれを実行する
    • 利点:クライアントをあらかじめ拡張できる
    • 例:JavaScript、Flash、Javaアプレット
    • 欠点:ネットワーク通信におけるプロトコルの可視性が低下する
      HTTPというアプリケーションプロトコルに従って通信している間は、通信の意味やアクセスするリソースが明白
  • ULCODC$SS
    = REST
    クライアント/サーバにコードオンデマンドまでを追加した複合アーキテクチャスタイルのこと
    実際にはRESTに基づいたアーキテクチャを構築する場合でも、RESTを構成するスタイルをいくつか除外することもありえる
    原則としてRESTとは、以下の6つを組み合わせたアーキテクチャスタイルのことを指す
    • クライアント/サーバ:ユーザインタフェースと処理を分離する
    • ステートレスサーバ:サーバ側でアプリケーション状態を持たない
    • キャッシュ:クライアントとサーバの通信回数と量を減らす
    • 統一インタフェース:インタフェースを固定する
    • 階層化システム:システムを階層に分離する
    • コードオンデマンド:プログラムをクライアントにダウンロードして実行する

RESTの2つの側面

  • RESTとハイパーメディア
    • 「アプリケーション状態エンジンとしてのハイパーメディア」
      = 「Web上のリソース同士が持つリンクをたどる」こと
    • アプリケーション状態
      例:ソーシャルブックマークアプリケーションの利用者が持つ状態
      「ブックマーク一覧を表示している」「新しいブックマークを追加しようとしている」
      ハイパーメディアのリンクをたどる作業によって遷移する
    • ハイパーメディアを用いたアプリケーションの利点
      リソースのURIさえ分かれば、あるアプリケーションが提供しているリソースをほかのアプリケーションでも簡単に再利用できる
    • 「持続性」という思想
      リソースをリンクで接続することでひとつのアプリケーションを構成する、という考え方
  • RESTと分散システム
    関数呼び出し回数の増加によるシステム全体の性能劣化を抑えるには、インタフェースの粒度を大きくして呼び出し回数を減らしたい
    • 分散システム
      サーバごとに別のインタフェースを持っている
      個々のインタフェースはプログラムライブラリのインタフェースをベースに開発することが多い
      通常のライブラリで良いとされるインタフェース(API)は、ネットワーク越しに呼び出すには粒度が細かすぎる
      RPCや分散オブジェクトではAPIの互換性を保ちにくい
    • RESTに基づいたWebサービス
      リソースはそれ自体で意味をもつひとかたまりのデータであり、粒度が大きい
      インタフェースが固定されているため互換性の問題は発生しない
      HTTPメソッドは常に固定である

Discussion

ログインするとコメントできます