リソース設計は、クライアントとサーバ間のインタフェース設計、つまりWebサービスやWeb APIの外部設計のことを言う。

設計のポイントは、どのようにリソースを分割し、URIで名前をつけ、相互にリンクを持たせるかという点。その際、WebサービスとWeb APIを分けて考えないということも大切。

リソース設計のアプローチ（読み取り専用）

リソース設計の指針として、『リソース指向アーキテクチャ』があり、このアーキテクチャでは4つの性質を満たす。

項目	説明
アドレス可能性	URIだけでリソースを一意に特定できる。
接続性	リソースをリンクで接続し、1つのアプリケーションを構成する
統一インタフェース	HTTPのように決められたメソッド（`GET/POST/PUT/DELETE等`）でアクセスする。
ステートレス性	状態を持たない通信。現実的にはCookieによるセッション管理が世の中の主流のため、そこまで重要でない。

設計アプローチは、次のステップから構成される。（ステップ４からは、それぞれのリソースに対して実施していく。）

Webサービスで提供するデータを特定する

サービスで提供するデータを理解し、特定する

リソースは、Web上に存在する名前のついた情報であるため、『当該のWebサービスが提供する情報は何か』について考え、リソースを分けていく。

注意としては、『何かを検索する』というのは機能であるため、『検索結果』という情報がリソースになる。

リソースがとして一意に定まるようなものはURIに組み込む。例えば、郵便番号のようなものは、それだけで一意に定まるため、次のようなURIになる。

http://example.com/1120002

クライアントからの入力を受け取るもの（検索等）は、次のようにクエリパラメータを利用する。

http://example.com/search?q=名古屋市

一部がパラメータとして変動するURIを記述する場合は、パラメータ部分をURI Templateという{}で括った表記が一般的。

http://example.com/search?q={query}

階層構造を持つリソースは/でURIを表現する。例えば、市町村であれば次のような表記になる。

http://example.com/{都道府県名}/{市町村名}/{町域名}

XML表現、軽量フォーマット表現、マルチメディア表現といった表現形式を決定する。1つのリソースが複数の表現形式をサポートしていると使い勝手が良い。

上記までで設計してきたリソースをリンクで接続する。トップページへのリンクやパンくずリストなどを用意するのが一般的。

接続した結果のリンク関係を図に起こしてあげると、リンク付け漏れなどの問題に気付きやすい。

Webサービス提供者が想定する標準的な利用コースを考える。ユースケース記述のようなものをイメージするとわかりやすい。

『存在しないURIを指定された』、『必須パラメータがない』、『サポート外のメソッドを使用』といった形で、どのような時にどんなステータスコードを返すかを検討しておく。

基本的なアプローチは読み取り専用時と同じだが、注意を払う必要がある処理もある。それぞれの処理および対応について、次にまとめる。

注意を払う処理	対応方法
複数リソースの更新	バッチ処理（作成・更新したいリソースを一括で送信）
複数ユーザによる同時書き込み	排他制御（複数のクライアントが同時に1つのリソースを編集して競合が起きないように、1つのクライアントのみが編集するように制御する）
複数の処理手順を必ず実行する	トランザクションリソース（複数のリソースにまたがった変更をひとまとまりに扱う

リソース設計のアプローチの『Webサービスで提供するデータを特定する』、『データをリソースに分ける』の部分がかなり苦労する。

その設計方法として次のものがある。