読み取り専用のWebサービスの設計

リソース設計

リソース設計において必要となるのはリソースの種類、リソースの操作方法、リソースとリソースのリンク関係など。
WebサービスとWeb apiは同じ技術を用い、同じアーキテクチャのもとで動いているのでを分けて考えないことが重要。
(別のものとして考えない)

リソース指向アーキテクチャのアプローチ

リソース設計として存在するリソース指向のアーキテクチャは

Webサービスで提供するデータを特定する
データをリソースにわける
リソースにURIで名前をつける
クライアントに提供するリソースの表現を設計する
リンクとフォームを利用してリソース同士を結びつける
イベントの標準的なコースを検討する
エラーについて検討する

のステップで設計をする。

イベントの標準的なコースの検討とは郵便番号のapiであれば郵便番号を検索する、住所から郵便番号を検索する、地域リソースの階層をたどりながら郵便番号を選択する、など。
エラーについての検討は存在しないURIの指定、必須のパラメータを指定していない、サポートしていないメソッドの利用など。

書き込み可能なWebサービスの設計

リソースの作成

リソースを作成するための特別なリソースをファクトリソースという。

リソースの更新

バルクアップデート

リソースを更新する際に、リソース全体を送信し更新する方法をバルクアップデートという。バルクアップデートはクライアント側の実装が簡単になるというメリットがある反面、送受信するデータが大きくなるというデメリットがある。

パーシャルアップデート

リソースを更新する際に、リソースの一部分だけを送信する方法をパーシャルアップデートという。パーシャルアップデートは送受信するデータの量が少なくなるというメリットの反面、GETしたリソースの一部を修正してそのままPUTする、という使い方ができなくなる。

サーバー側でパーシャルアップデートをサポートする場合には、バルクアップデートもサポートするのが望ましい。

バッチ処理

バッチ処理のリクエストを受け付けたサーバーはデータを分解し、それぞれの更新処理を行う。途中でエラーが起きてしまった場合の対処法は2つあり、1つはバッチ処理を トランザクション化 し、途中で失敗した場合には何も処理しないことをwebサービスの内部で保証する方法。もう1つは処理が成功したリソースと失敗したリソースをクライアントに伝えるという方法。

排他制御

悲観的ロック

ユーザーをあまり信用せずにリソース編集の競合が決して起きないようにするためにロックの権限を持った人以外が編集できないように制限するのが悲観的ロック。少人数で用いる際には誰がロック中なのか、というのが簡単にわかるけれど、世界中の不特定多数のユーザーが同時に編集するような大規模システムでは、文書をロックしたままずっと編集できないなどの問題が発生する。

楽観的ロック

常に同じ文章を複数の人が編集し続けることはないという経験則から、通常時はロックせずに、競合が起きたときのみロックする方法が楽観的ロック。頻繁に更新が起きない場合などに採用する。

設計のバランス

Webサービス設計において

なるべくシンプルに保つ。不要な機能の削除等。
困ったらリソースに戻って考える。検索機能の実装をする際にSEARCHメソッドを追加するのではなく、検索結果リソースをGETするという考え方。
PUTが更新処理として使うメソッドではあるが、バッチ処理などの際にPOSTメソッドの方が優れている場合にはPOSTメソッドを用いる。

等のことが大事である。

リソースの設計

関係モデルからの導出
オブジェクト指向モデルからの導出
情報アーキテクチャからの導出

等のやり方がある。関係モデルからの導出、オブジェクト指向モデルからの導出はいくつか注意点を押さえれば十分にリソース設計ができる。この中で特に情報アーキテクチャからの導出は相性がよい。ただし、設計手法としてはまだ完成度が低いため、これから成長していく分野である。