^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          summary
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

5部 Webサービスの設計
  • 読み取り専用のWebサービス設計
  • 書き込み可能なWebサービス設計
  • リソースの設計

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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


検索などクエリパラメータを受けとりリソースを返す場合は.json.htmlなどの様に拡張子で区別せず、typeパラメータを使用する方が自然。

1 # クエリパラメータを受け取ららない場合
2 http://zip.ricollab.jp/東京都/文京区/小石川.json
3 
4 # クエリパラメータを受け取る場合
5 http://zip.ricollab.jp/search?q="小石川"&type=json

HTMLにて特定の記事のリンクを貼るように、WebAPIも次の記事のリンクを提供すると親切。検索結果が複数ページにまたがる場合に次のページのリンクを追加するなども同様。

 1 {
 2   "query": "112",
 3   "next": "http://zip.ricollab.jp/search?q=112&type=json&page=2"
 4   "result":[{
 5     "zipcode": "1120000",
 6     "address": "東京都文京区小石川",
 7     "link": "http://zip.ricollad.jp/1120000"
 8   },
 9   {
10     "zipcode": "1120001",
11     "address": "東京都文京区白山",
12     "link": "http://zip.ricollad.jp/1120001"
13   }]
14 }

16章.書き込み専用のWebサービス設計


リソースの更新
  • バルクアップデート
    • 更新以外の全ての情報を送受信する。
    • クライアントの実装が簡単になる。
    • データ量が多いためAjaxなどの非同期通信では不向き。
  • パーシャルアップデート
    • 更新情報のみ送受信する。
    • データ量が少なくて済む。
    • GETしたリソースを一部修正してそのままPOSTすることができない。

サーバ側でパーシャルアップデートをサポートする場合は、バルクアップデートもサポートするのが一般的。

トランザクション
  • 処理をトランザクションリソースへ送信し、トランザクションの実行リクエストが送信されたタイミングで処理を行う。失敗時にロールバックする。
  • 複数リソースへの処理をPOSTで一括にリクエストする。失敗時にロールバックする。
排他制御
  • 悲観的ロック
    • リソースをロックすることで排他制御を実現する方式。
      1. WebDavのLOCK/UNLOCKを使用する。
      2. LOCK相当の機能をサーバ側で用意する。 
    • 多数のユーザが同時に編集できない、などの問題が発生する。
    • 少人数向き
  • 楽観的ロック
    • 競合発生時に適切に対処することで排他制御を実現する方式。
      1. 条件付きリクエストにてリソースの更新状態を把握し競合に対処する。
    • 不特定多数向き

17章.リソース設計


  • リソース設計には決まりきった設計法が定まっていないので、ER図やクラス図などよりリソースを抽出、階層化すると良い。
  • リソースを設計する上で大切なことは「WebサービスとWebAPIを分けて考えないこと」。人間用、プログラム用とインターフェスは違いこそあれど提供するものは同じリソースであり、技術的違いも少ないため分ける必要がない。



comments powered by Disqus


© 2015 kyuden