Skip to content

Instantly share code, notes, and snippets.

@tkawa
Created May 19, 2015 09:46
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tkawa/def1fbadba33177cb94b to your computer and use it in GitHub Desktop.
Save tkawa/def1fbadba33177cb94b to your computer and use it in GitHub Desktop.
RESTful#とは勉強会7 ポイント

RESTful#とは勉強会7 2015.05.19

質問はTwitterへ #RESTudy をつけてどうぞ。

「Webを支える技術」第8章 ステータスコード (8.5 p.121〜)

重要な用語・概念

以前に出てきた用語が多いので、理解が不安なときはその都度前のページを振り返って復習しながら進みましょう。

  • ボディ(レスポンスボディ) →6.6 p.76
  • リクエスト/レスポンス → 6.5 p.73

Webサービスの場合も404 Not Foundで返すべき情報を200 OKで返すと、 検索エンジンのロボットが正式なリソースであると勘違いし、インデックス処理が行われてしまうなどの問題が生じる可能性があります。

このことを俗に「ソフト404」と呼びます。

存在しないページに対して 404 と 410 以外のコードを返すこと(または 404 を返す代わりにホームページなど他のページにリダイレクトすること)は、問題となる可能性があります。まず、その URL にページが存在することが検索エンジンに明示されます。その結果、URL がクロールされ、コンテンツがインデックスに登録される場合があります。存在しないページに対して Googlebot の時間が消費されるため、所有している固有の URL の検出が遅れたり、アクセスの頻度が少なくなったりする可能性があります。また、サイトのクロール範囲にも影響する可能性があります(検索クエリ「ファイルが見つかりません」でサイトが上位にランクされることは避ける必要があります)。

グループで考えてみよう

エラーのとき、Webサイトはどのようなボディを返しているでしょうか。よく使っているWebサイトの404ページを見てみましょう。実際にステータス404になっていることを確かめましょう。

最近のWeb APIはJSONが多く使われています。この場合、エラーメッセージもJSONで返すのがよい方法です。どのようなJSONを返すのがよいでしょうか。 (JSONについては第14章にも説明があります)

「ソフト404」はよくありません。実際に『ファイルが見つかりません』で検索してみるとどうなるでしょう。

解説

Problem Details for HTTP APIs というエラーの詳細を表現するJSONフォーマットがあります(期限切れのインターネットドラフト)。これを参考にするのもよいでしょう。 https://tools.ietf.org/id/draft-ietf-appsawg-http-problem-00.txt

「残高が足りない」エラーの例

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Content-Language: en

{
 "type": "http://example.com/probs/out-of-credit",
 "title": "You do not have enough credit.",
 "detail": "Your current balance is 30, but that costs 50.",
 "instance": "http://example.net/account/12345/msgs/abc",
 "balance": 30,
 "accounts": ["http://example.net/account/12345",
              "http://example.net/account/67890"]
}

ライブラリ

RESTfulなサイト作り~ひよこ編~

「Webを支える技術」第15章 読み取り専用のWebサービスの設計 は、郵便番号検索サービスの設計を行っている章です。 次回以降に実際に設計してみる準備として、この章を読みながら、他の郵便番号検索サービスと比べて設計の違い、自分が作るならどうするかを話し合いましょう。

範囲:15.1(p.242)〜15.5(p.247)

①〜⑦までのステップがありますが、今回は ①「Web サービスで提供するデータを特定する」は書いてある通りのデータを前提に、 ②「データをリソースに分ける」をメインに考えましょう。

郵便番号検索サービスの例:

「Webを支える技術」本文掲載のURLは実際にアクセスできるWebサービスです。実際に見て比べてみるとわかりやすいでしょう。

考えるポイント

①「Webサービスで提供するデータを特定する」(15.4)はそのままCSVデータを使います。

13105,"112  ","1120002","トウキョウト","ブンキョウク","コイシカワ","東京都","文京区","小石川",0,0,1,0,0,0
  • 7 桁の郵便番号
  • その郵便番号が表現する住所(都道府県名、市町村名、町域名)
  • 住所のカタカナ読み

実際にはもう少し詳細ですね。

②「データをリソースに分ける」(15.5)

  • 郵便番号リソース
  • 検索結果リソース
  • 地域リソース
  • トップレベルリソース

本書ではこの4種類のリソースを導き出していますが、これが必ず正解というわけではありません。他のサービスではどのようになっているでしょうか。自分ならどのようなリソースを作りますか?

調べ方のヒント

ブラウザのデベロッパーツールを使いましょう。
Windows: F12Ctrl+Shift+i
Mac: command+option+i

Networkタブのリクエストやレスポンスを見て、URLやメソッドを調べましょう。

REST復習の参考スライド

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment