RESTful API
RESTful API
まず、ウィキペディアの定義を要約してみたら、以下のようになります。
ワールドワイドウェブ（World Wide Web a.k.a WWW）などの分散ハイパーメディアシステムのためのソフトウェアアーキテクチャ形式であり、リソースを定義し、リソースに対するアドレスを指定する方法全般に関するパターン。
RESTとは、REpresentational State Transferの略称です。ここに-fulという形容詞的接尾辞を付けて、RESTfulなAPIという表現で使用されます。つまり、RESTの基本原則を忠実に守ったサービスデザインは、RESTfulであると表現することができます。
RESTは、分散ハイパーメディアシステム、例えばWorld Wide Web(WWW)向けのソフトウェアアーキテクチャの一形式で、リソースを定義し、リソースに対するアドレスを指定する方法全般に関するパターンです。
RESTはデザインパターンであり、アーキテクチャであるという話がありますが、より正確に言うと、RESTはリソース指向アーキテクチャ(Resource Oriented Architecture)です。API設計の中心にリソース(Resource)があり、HTTPメソッドを使ってリソースを処理するように設計することです。
REST 6つの原則
・Uniform Interface
・Stateless Caching
・Client-Server
・Hierarchical system
・Code on demand
RESTfulにAPIをデザインするとは何を意味するのか。(要約)
-
リソースと動作を明確かつ直感的に分離します。
・リソースはURIで表現されるため、リソースが指すものは名詞で表現されるべきです。
・動作はHTTPメソッドで表現し、GET(参照)、POST(作成)、PUT(既存のエンティティ全体の修正)、PATCH(既存のエンティティの一部修正)、DELETE(削除)を明確な目的で使用します。
-
メッセージは、ヘッダと本文を明確に分離して使用します。
・エンティティに関する内容は本文に格納します。
・アプリケーションサーバが行動する判断の根拠となるコントロール情報であるAPIバージョン情報、レスポンスするMIMEタイプなどは、ヘッダに格納します。
・ヘッダと本文は、httpヘッダとhttp本文に分けることもできますし、http本文に入るjson構造に分離することもできます。
-
APIのバージョンを管理します。
・環境は常に変化するため、APIのsignatureが変更される可能性があることに注意してください。
・特定のAPIを変更する場合は、必ず下位互換性を保証する必要があります。
-
サーバとクライアントが同じ方法を使用してリクエストするようにします。
・ブラウザはform-data形式のsubmitで送信し、サーバー側はjson形式で送信するような分離よりも、jsonで送信するか、どちらもform-data形式で送信するか、1つに統一します。
・別の言い方をすると、URI はプラットフォームに中立的でなければなりません。
どのような利点があるのか？
-
Open API を提供することが容易である。
-
マルチプラットフォームをサポートし、連携が容易である。
-
希望するタイプのデータを送受信することができる。
-
既存のウェブインフラ(HTTP)をそのまま利用することができる。
欠点は何か？
-
使用できるメソッドが限定されている。
-
分散環境には不適している。
-
HTTP通信モデルに対してのみサポートされている。
Comments