読書感想文

個人的に理解できた内容とかについて簡単にまとめてみる 
ぶっちゃけこのへん知らなくてもモノは作れたりするあたり怖いなぁと思った。 
あと、読んだ感想としては知らないこととかこれってどこでつかうんだろうとか 
まぁ色々考えないといけないところがおすすめされる理由がなんとなくわかった気がする。 
漠然とわかった気になってたピースを一つに集めるとこうなるのかーってｗ 
俺こんなことも知らなくてエンジニア・・・まじか・・・やっぱり死んだほうがいい。
ちなみに1周したぐらいじゃ僕は理解できなかったので2周目まったなしっすわｗ

REST

一般によく使われる狭義のRESTは、パラメータを指定して特定のURLにHTTPでアクセスすると、
XMLで記述されたメッセージが送られてくるようなシステムおよび呼び出しインターフェース(「RESTful API」と呼ばれる)のことを指す。
システムの状態やセッションに依存せず、同じURLやパラメータの組み合わせからは常に同じ結果が返されることが期待される。
ただし、厳密な技術的定義が共有されているわけではなく、「SOAPやRPCなどを必要としない、XMLベースの単純なWebインターフェース」くらいの意味で用いられる場合が多い。

RESTとは設計原則は以下の４つの項目で成り立っている

セッションなどの状態管理を行わない(やり取りされる情報はそれ自体で完結して解釈することができる)
- Webシステムでは、HTTP自体にはセッション管理の機構はない
情報を操作する命令の体系が予め定義・共有されている
- WebシステムではHTTPのGETやPOSTなどに相当
すべての情報は汎用的な構文で一意に識別される
- URLやURIに相当
情報の内部に、別の情報や(その情報の別の)状態へのリンクを含めることができる
- ハイパーメディア的な書式で情報を表現する(HTMLやXMLに相当)

URI

URIとURLの違い

URL（Uniform Resource Locator）：
　場所を示す書き方のルール。
　ページや画像などを取得したりするための主要な場所とアクセス方法を指定。
　例：（Web担トップページの場所とアクセス方法）
　　http://web*tan.forum.impressrd.jp/
URN（Uniform Resource Name）：
　名前を永続的に識別する書き方のルール。
　これ単体ではアクセスできない場合もある。
　例：（Web担のムックの最新刊）
　　urn:isbn:4844327968
URI（Uniform Resource Identifier）：
　名前または場所を識別する書き方のルールの総称（親玉）。
　URLやURNは、URIで定められたルールに従って書かれたり使われたりする。

目指すべきはクールなURI

URIは変わらないべきである
変わらないURIこそが斎場のURIである
URIには長さは制限がある
- IEがバージョンを問わず2038バイトの制限がある
- そのため2038バイトを超えないようにする必要がある

設計する上で気をつけたいこと

プログラミング言語に依存する拡張子を使わない
実装依存のパス名を利用しない
プログラミング言語のメソッド名を利用しない
セッションIDを含めない
URIはリソースを表現する名詞である

HTTP

HTTPってなに

HTTPは、 「Hyper Text Transfer Protocol」の略です。
今やインターネットの代名詞となったWWW上でWebサーバとクライアントが、 HTMLで書かれた文書などの情報をやりとりする時に使われる通信手順(プロトコル)を意味します。
基本的には普通のテキストデータを使い、 ブラウザなどのクライアントがWebサーバに対してget、putといったコマンドを送ると、 それに応じた結果がサーバから送られてきます。 送られてきた結果であるHTML、 JPEGといったデータをきれいに成形して見せるのは、 Webブラウザの仕事になっています。

HTTPとHTTPSの違い

HTTP通信
- データが暗号化されていない
HTTPS通信
- 暗号化されている

リクエストとレスポンス時に行われている動き

クライアント側
1. リクエストメッセージの構築
2. リクエスト・メッセージの送信
3. (レスポンスが返ってくるまで待機)
4. レスポンスメッセージの受信
5. レスポンスメッセージの解析
6. クライアントの目的を達成するために必要な処理
サーバ側
1. (リクエストの待機)
2. リクエストメッセージの受信
3. リクエストメッセージの解析
4. 適切なアプリケーションへの処理の移譲
5. アプリケーション・プログラムから結果を取得
6. レスポンスメッセージの構築
7. レスポンスメッセージの送信

メソッドは8種類

get
- リソースの取得
post
- 子リソースの作成、リソースへのデータ追加、その他の処理
put
- リソースの更新、リソースの作成
delete
- リソースの削除
HEAD
- リソースのヘッダ(メタデータの取得)
OPTIONS
- リソースがサポートしているメソッドの取得
TRACE
- 自分宛てにリクエスト・メッセージを返す
CONNECT
- プロキシ動作のトンネル接続への変更

JSON

JSON（ジェイソン、JavaScript Object Notation）は軽量なデータ記述言語の1つである。構文はJavaScriptにおけるオブジェクトの表記法をベースとしているが、JSONはJavaScript専用のデータ形式では決してなく、様々なソフトウェアやプログラミング言語間におけるデータの受け渡しに使えるよう設計されている。

設計で注意しないといけないこと

トランザクション

トランザクションとして管理された処理は「すべて成功」か「すべて失敗」のいずれかであることが保証される。例えば、資金移動システムをコンピュータで処理する場合、出金処理と入金処理は「どちらも成功」か「どちらも失敗」のどちらかであることが要求される。「出金に成功して入金に失敗」すると、出金された資金が宙に浮いてしまうからである。

このような場合に、出金と入金をまとめて一つのトランザクションとして管理し、どちらか一方が失敗したらもう片方も取り消し、どちらも成功したときに初めて全体を成功として確定する。このような管理を専門に行うソフトウェアをTPモニタ(Transaction Processing monitor)ということがある。

排他制御

悲観的ロックとは

自分が操作している情報は，他の人も操作する可能性があるという視点に立った排他制御方法である． 悲観的ロックの特徴は，画面に表示した情報は，自分が変更するまで保証されている点である． この特徴が利点となるのは，在庫確認をして，在庫があれば，出庫処理をするような在庫管理の業務の時である。なぜなら，このような在庫管理のシステムでは，確認している最中に在庫数が変化したら，システムが立ち行かなくなってしまう。つまり，悲観的排他により「同時に倉庫に入れる人はひとり」と取り決めるようなものである。 　リストでは，他の利用者が情報を参照していると同一情報の参照が待たされる。

メリット
- プログラムで気にする必要がない
- 複数のトランザクションを順番に処理できる
デメリット
- デッドロックが発生する恐れがある
- ロックの間トランザクションを維持しておかないといけない
楽観的ロックとは

楽観的ロックとは、テーブルにもたせている更新タイムスタンプや、更新フラグを比較してロックするというものである。 例えば更新したいレコードを取得して、更新タイムスタンプを保持しておく。 そして、更新する直前に再度レコードを取得して更新タイムスタンプが最初の時と変わっていないかどうかで、排他処理を行うというものである。　

その結果、帰ってきた値が0ならば、更新失敗となり、１ならば成功となる。 このように楽観的ロックは比較的簡単で自分が操作している情報は，他の人が操作する可能性が少ない時に主に多用される。