読者です 読者をやめる 読者になる 読者になる

「Webを支える技術」読書録

「Webを支える技術」を読んだのでまとめを作成する。


・REST
 RESTとはネットワークシステムのアーキテクチャスタイルの1つ
 
    RESTの構成
    下記6つを組み合わせたアーキテクチャスタイル
 ・クライアント/サーバ    :ユーザインタフェースと処理を分離する
 ・ステートレスサーバ        :サーバ側でアプリケーション状態を持たない
 ・キャッシュ                    :クライアントとサーバの通信回数と量を減らす
 ・統一インタフェース        :インターフェースを固定する
 ・階層化システム                :システムを改装に分離する
 ・コードオンデマンド        :    プログラムをクライントにダウンロードして実行する

 RESTの重要な概念の1つにリソースがある。
 ・リソースとはWeb上の情報のこと
 ・リソースはURIで一意の名前を持つ
 ・URIを用いることでプログラムはリソースが表現する情報にアクセスできる

URI
    URIとはリソースをと統一的に識別するID
 「変わらないURIが最上のURIである」    
  URIの設計方針
  ・プログラミング言語依存の拡張子を使わない
  ・実装依存のパス名を利用しない
  ・プログラミング言語のメソッド名を利用しない
     ・セッションIDを含めない
  ・リソースを表現する名詞を使うべき

 

TCP/IPとは
 ・ネットワークインタフェース層
  物理的なケーブルやネットワークアダプタに相当する部分
 
 ・インターネット層
  TCP/IPではIPの部分。データ送信を保証する。
  ネットワークでデータのやりとりを行う部分。
  IPではパケット単位でやりとりして通信する。

 ・トランスポート層
  TCP/IPではTCPの部分。データ転送を保証する。
  接続先の相手にコネクションを張ってデータの抜け漏れをチェックして保証する。

 ・アプリケーション層
  メールやDNS、HTTPなどの具体的なアプリケーションを実現する。

・HTTPメソッド
 GET:リソースの取得
 POST:リソースの作成・追加
 PUT :リソースの更新・作成
 DELETE:リソースの削除
 HEAD:リソースのヘッダ(メタデータ)の取得
 OPTIONS:リソースがサポートしているメソッドの取得
 
POSTとPUTの使い分け
・POSTでリソースを作成する場合は、クライアントはリソースのURIを指定できない。(URIの決定権はサーバ側にある)
・PUTでリソースを作成する場合は、クライアントがリソースのURIを指定する。

べき等性と安全性
・べき等性:ある操作を何回行っても結果が同じこと
・安全性:操作対象のリソースに副作用がないこと
 
GET、HEAD:べき等性かつ安全
PUT、DELETE:べき等だが安全でない
POST:べき等でも安全でもない

ステータスコード
・1xx:処理中
・2xx:成功
・3xx:リダイレクト
・4xx:クライアントエラー

HTTPヘッダ
概要
・メッセージのボディに対する付加的な情報(メタデータ
・ヘッダの情報を元にクライアントやサーバは挙動を変化させる

具体的に実現してる機能
・リソースのアクセス権を設定する認証
・クライアント・サーバ間の通信回数と量を減らすキャッシュ

JSONJavaScript Object Notation)
JavaScriptの記法でデータを記述できる
・データ型:オブジェクト、配列、文字列、数値、ブーリアン、null

JSONPJSON with Padding)
Ajaxで用いるXMLHttpRequestというJavaScriptモジュールは取得サーバと同じサーバ内でしか通信できない。
 別のサーバと通信できてしまうと、ユーザが知らない間にデータを不正なサーバに送信できるというセキュリティ上の問題が発生するから。
 この問題を解決するために、HTMLのscriptタグでJavaScriptファイルを読み込んで、その中に書いてある関数をクライアントが任意のタイミングで呼び出して
 クロスドメイン通信を実現する手法がJSONP


・リソース指向アーキテクチャ設計
1)Webサービスで提供するデータを特定する
2)データをリソースに分ける
3)リソースにURIで名前をつける
4)クライアントに提供するリソースの表現を設計する
5)リンクとフォームを利用してリソース同時を結び付ける
6)イベントの標準的なコースを検討する
7)エラーについて検討する

RESTfulなWebサービスの性質
・アドレス可能性
・接続性
・統一インタフェース
・ステートレス例

ルクアップデート
・リソース全体を送信して更新する方法

パーシャルアップデート
・リソースの一部分を送信して更新する方法

設計のバランス
・なるべくシンプルに保つ
・困ったらリソースに戻って考える
・本当に必要ならPOSTで何でもできる

リソース設計の手法
・関係モデル
オブジェクト指向モデル
情報アーキテクチャ(相性が良い)

WebサービスとWebAPIを分けて考えないことがリソース設計で最も重要