//tips
//webapi理解継続
Webapiの設計で手のかかる部分はリクエストに対するレスポンス設計であることがわかってきた。
どのuriにどの機能をつけ、そこにアクセスするクライアントの要望をなるべく満たすようにデータベース内の該当項目を抽出加工して、レスポンス内容に反映してあげる必要がある。
プログラミングというよりは一度覚えてしまえばルーチンの作業としてこなせそう。
一通り理解した後、なんらかの形で使えるサーバーを用意し、そこにアップデートしたデータベースを反映するwebページに対して、Unityアプリからapi経由で指示を出し、ページに反映させるということをやってみる。
Webページには簡単なボタンと数字を用意し、ボタンプッシュによるカウント増加機能と同等の機能をunityアクセスから実行できるようにする。
今理解している内容であればapiでこれが実現できるはず。
また、一度受け取った情報をクライアント側で保存しておくキャッシュは積極的に活用しておくべきだが、中継するプロキシサーバーもキャッシュを行なっている場合があり、その場合には、サーバー側からプロキシ側にキャッシュ情報を送ってあげる必要がある。
というのもサーバ側で情報が更新しているにもかかわらず、プロキス側がキャッシュされている古い情報を送ってしまう可能性があるので。
ApiのキャッシュはHTTPのキャッシュ機能を利用する。
キャッシュの方法は期限切れモデルと検証モデルがあり、下記のようになる。
期限切れモデル：レスポンスデータに保存期限を設定し、期限が切れたら再度アクセスして情報取得
→Cache-Controlレスポンスヘッダを使用
Cache-Control:max-age=3600 //これは秒数表示
→Expiresレスポンスヘッダを使用
Expires: Fri, 01 Jan 2016…
検証モデル：現在のキャッシュが最新のものか都度問い合わせ、変更があった場合に取得を行う
これは都度通信が発生してしまうので、リクエスト頻度が少なく、データ容量が大きい時に有用な仕組みとなる。
条件付きリクエストの場合は、クライアントが現在保持している情報のstateをサーバ側が知る必要があるので、最終更新日(Last-Modified)または、リソースのバージョンを表す識別子エンティティタグ(ETag)のどちらかを利用して、更新情報を送るかどうかをサーバ側で判断する必要がある。
Etagの生成方法はサーバ側で決める必要がある。
最終更新日をもとに条件付きアクセスを行う場合は、
GET/v1/users/1234
If-Modified-Since:Tue,01 Jul…
エンティティタグを使う場合は、
GET/v1/users/1234
If-None-Match:…
とする。
サーバ側は送られてきた情報に変更がなければ304を返し、変更があれば200の成功を返し、情報を送付する。
エンティティタグのハッシュ生成はMD5やSHA1などの関数が利用されているよう。
株価情報などのキャッシュをして欲しくないものに関しては
Cache-Control: no-cache
のようにする。
同時にキャッシュをする際に、知っておく必要があることとして、同一URIでもリクエストヘッダの内容でデータが異なるケースが存在する。
例えば、ホームページの言語表示などがあり、Accept Languageというヘッダに対応し、自動で取得する緯度軽度からレスポンスデータに含まれる言語を切り替えるようになっているため、同一uriでも異なる言語表示がなされてしまうことが生じる。
そこでVary : Accept-Languageを用いることでキャッシュするリクエストヘッダも指示する。
モバイル表示などもVaryでの対応となる。
