APIの始め方(Caching, Scalability)
Aug 28, 2017 · 4 min read
前回は、API開発における日時の管理、またセキュリティについてまとめました。今回は、Cachingについて学んでいきます。
サービスは、応答にヘッダーを設定することでキャッシュ機能を強化します。 しかし、HTTP 1.0のキャッシュ関連のヘッダーはHTTP 1.1のものと異なる為、サービスは両方のHTTPをサポートする必要があります。
まずは、次のリスポンスデータのheaderをみていきます。
Cache-Control: 86400
Date: Wed, 29 Feb 2012 23:01:10 GMT
Last-Modified: Mon, 28 Feb 2011 13:10:14 GMT
Expires: Thu, 01 Mar 2012 23:01:10 GMTAnd below is an example of a similar response that disables caching altogether:
Cache-Control: no-cache
Pragma: no-cache
それぞれのフィールドは、次のようになります。
Dateデータ(Response)が返された日時Cache-ControlレスポンスデータがCacheされる最大分。レスポンスにCash機能を持たせない場合は、例のようにno-cacheとなるExpiresもしCacheがサポートされていな時、このフィールドはない。Date + Cache-Controlの時間(返された時+キャッシュの有効時間)になるPragmaもしCacheがサポートされない時、このヘッダーもno-cacheとセットされる。Last-modifiedリソースそれ自体が、最後に修正された日時
また、ETagヘッダーは、キャッシュされた表現の新鮮さを検証し、条件付き読み取りおよび更新操作(それぞれGETおよびPUT)を補助します。
ファイル形式ごとに異なる値が当てはまりますが、次のようなheaderをGET毎に持たせます。値が””ダブルクオートで囲まれることに、注意します。
ETag: "686897696a7c876b7e"以上がCashing処理になります。
さて。今まで出てきたHTTPステータスコードを、急にまとめたくなったので、よく使われる次の10個を確認します。
- 200(OK)
→成功status。APIで返されるデータの、ほとんどの成功は、200で表されます。 - 201(CREATED)
→POSTやPUTで新規に作成されたURIの成功を表します。Locationヘッダーに、新規作成のリンクが含まれます。 - 204(NO CONTENT)
→ラップされたレスポンスが使われず、本文に何も内容が無い時(DELETE) - 304(NOT MODIFIED)
→条件付きGET呼び出しに応答して使用されます。これを使用する場合は、Date、Content-Location、Etagヘッダーを通常のGET呼び出し時のものに設定する必要があります。 - 400(BAD REQUEST)
→ドメイン名やリスエストに必要なデータがそろっていない時に起こります。 - 401(UNAUTHORIZED)
→認証されなリクエストの場合 - 403(FORBIDDEN)
→操作を実行する権限がないユーザーに返されます。 - 404(NOT FOUND)
→リクエスト要求するAPIがない場合、また401や403である場合に使われます。 - 409(CONFLICT)
→要求を満たすことによってリソースの競合が発生するごとに使われます。 - 500(INTERNAL SERVER ERROR)
→server側でエラーが出た時は、通常500エラーが起こります。
以上が、主なHTTPステータスコードになります。
