Help us understand the problem. What is going on with this article?

「Webを支える技術」読書レポート

More than 1 year has passed since last update.

概要(著作、著者、著者経歴)

Webを支える技術

の読書レポートです。

参考にした書き方

著者:山本陽平
著者経歴:
1975年生まれ。株式会社リコーグループ技術開発本部にてWebに関連した研究開発に従事。

山本さんのブログ
http://yohei-y.blogspot.jp/

要約

Webエンジニアであれば、誰もが知っている用語「HTTP」「URI」「HTML」「JSON」などの詳細、歴史的経緯、実用例を解説しながら、
「REST」というWebサービスの設計思想を教えてくれる本です。

面白かった章と解説

第一部 1~3章

Webは現代社会ではなくてはならない存在であり、多くの人が常に使っている。
そのWebの根幹であるRESTは、とてもシンプルに構成されていて、
シンプルさがWebに受け入れられている点が面白いと感じました。

RESTはシンプル

一言でまとめると

RESTというアーキテクチャスタイル(設計モデル)は
「統一されたインターフェースを用いて、
クライアント/サーバ間で処理を分けるステートレスな分散処理モデル」

詳しく説明すると

RESTとは、下記の6つの特徴を併せ持つ。

  • クライアント / サーバ:見た目(ユーザインタフェース)と処理を分断する。
  • ステートレスサーバ:サーバはクライアントの情報を持たないことにより、サーバ同士でクライアントの情報を共有する必要がなくなる。
  • 統一されたインターフェース:一意に決められたリソースの場所に対して、統一されたインターフェースで操作する。
  • 階層化システム:クライアントとサーバ間にプロキシやロードバランサを挟むことが出来る。
  • キャッシュ:更新頻度の少ないリソースは、キャッシュから使用する。
  • コードオンデマンド:クライアント側での実行処理は、サーバからダウンロードして実行。

具体的には

RESTfulな(RESTに基づいた設計)Webサービスを作る場合、
「HTTP」プロトコル(統一インターフェース)で
「URI」(一意に決められたリソースの場所)を指定して、
「HTML」や「JSON」をCRUD(作成,読み込み,更新,削除)するサービスとなる。

疑問点

RESTに反すること

p.32
RESTfulなシステムであっても、完全にRESTに合わせることは難しいので、
例外も発生するとの記述があった。(セッション管理を使うことで、ステートレスではなくなるなど)

例えば、RedisなどのDBでユーザ情報を持たせることもステートレスと反するのか?
https://qiita.com/hash/items/1b0abe07544b81457ad0

Cool URIではないもの

p.64
いいURIとは、リソースの場所を示す名詞であるべきとの記述があったのだが、
Railsの標準ルーティングのeditやnewは名詞ではないので、いいURIではないのか?

https://railsguides.jp/routing.html#crud%E3%80%81%E5%8B%95%E8%A9%9E%E3%80%81%E3%82%A2%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3

リソース設計をするタイミングがよくわからない

今回、リソース設計の紹介がありましたが、この設計をするタイミングが分からない
Webサービスを設計するに当たって、

  • クラス設計
  • テーブル設計
  • リソース設計

とアプリケーション側で三つも存在することになり、
新規でWebサービスを構築するときは、
どの設計から始めればいいのか?
もしくは三つの設計を少しずつ繰り返し作って、完成させればいいのか?
がよく分からない。

仕事に活かせそうな知識、活かせそうな状況と活かし方

HTTPヘッダを用いたデバッグ

HTTPヘッダを確認することにより、
Ajaxなどで、どのURIにリクエストを送って、何のレスポンスが返ってきているのかを確認することが出来るようになった。
サーバのログやクライアントのコンソールだけでは、分からない部分もデバッグ出来る。

  • レスポンスのステータスコードの確認
  • TwitterなどのAPIをクライアントから叩いたときに、返ってくる値をJSONで確認
  • クライアントがPostした内容の確認など

また、この本を読んだあとに、Chromeからリクエストとレスポンスの中身は読めるようにしておいた。

ChromeでのPostリクエスト,レスポンス確認方法

https://qiita.com/CASIXx1/items/4ec20d9f463fd3d390de

URI設計

今まで、ディレクトリマップ、Webディレクターに任せることが多かったのだが、
良いURIの定義を学ぶことにより、エンジニアでもディレクトリマップを設計やレビューをすることが可能となる。

良いURIとは?

  • URIはリソースを指すので、動詞ではなく名詞であるべき
  • 言語やサーバに依存させないなど

APIやフレームワークの評価

  • どのメソッドとURIから、どのアクションを呼び出すべきなのか (CRUDとHTTPのメソッドの対応関係)
  • RESTfulになっているかどうか
  • リソース設計出来ているかどうかの検討

次に読みたい関連書籍

今回は、REST,HTTP,URI,HTMLに関しての基本を学ぶことが出来たので、
その知識を活かして、Web APIに関する本を読みたい。

Web API: The Good Parts

他には
Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術

情報アーキテクチャ 第4版 ―見つけやすく理解しやすい情報設計

サービスデザインパターン SOAP/WSDLとRESTful Webサービスの基本的な設計ソリューション

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした