Engineerになりました。備忘録も兼ねて技術ネタを適当に。技術以外はこっち→http://mitsu9.hatenablog.com/この広告は、90日以上更新していないブログに表示しています。-HTTP、URI、HTML、そしてREST-」を読んだ(/・ω・)/これまでWebサービスを使ったり、実装したりとしてきたけど、改めて体系的にWebについて勉強するといろいろ良かった。就職前に読んでおいて良かったなーと思った。Webサービス作り始めの頃とかに読んでおきたかった。各章で書いてあったことと感じたことをメモしておく。Webとは何かさまざまなWebWebサイトユーザーインターフェースとしてのWeb(ルータの設定画面など)プログラム用APIとしてのWebWebっていろんなところで使われてるねって話。Webの歴史Web以前のインターネット・ハイパーメディアの紹介・問題点Webの登場と標準化の歴史Web以前のインターネットとか知らないことが多くておもしろかった。アーキテクチャスタイルクライアント/サーバステートレスサーバキャッシュ統一インターフェース階層化システムコードオンデマンドWeb世界の秩序を守るためにもRESTfulなサービスやAPIを作ろう。IdentifierURIスキームユーザ情報ホスト名ポート番号パスクエリパラメータURIフラグメント絶対URIと相対URI相対URIを使うときはベースURIが必要ベースURIはHTMLので指定できるURIで使用できない文字を使うときはUTF-8で%エンコーディングする相対URIとかは気にしたことなかったので勉強になった。変わらないURIURIが変わるときはリダイレクトするURIの重要性URIはリソースの名前URIは寿命が長いURIはブラウザがアドレス欄に表示するリンク先に飛んだら404とか悲しい気持ちになるし、Web的にも良くないよね。良いURIをつけられるようになろう。1.1が今広く使われているリクエストメッセージリクエストラインヘッダボディレスポンスメッセージステータスラインヘッダボディステートレス利点:サーバはアプリケーション状態を覚える必要がない→シンプル、スケーラブル欠点:パフォーマンスの低下、通信エラーへの対処HTTPは凄いシンプルなプロトコル。ここまで広く使われているんだろうなーと思った。一方でシンプルだからこその欠点もあるのでそれは知っておく必要があるしいい勉強になった。操作対象のリソースの状態を変化させないべき等と安全は意識しないと、使い勝手の悪いサービスを作ってしまうなーと感じた。ステータスコードステータスコードの重要性クライアントの挙動を決める間違ったステータスコードはクライアントを混乱させるステータスコードは自作できるクライアントが未知のステータスコードを受け取った場合は、先頭数字を見て最低限の処理をおこなう良くみるステータスコードは勝手に覚えてるけど、それ以外のものはいつかゆっくり見てみたい。認証キャッシュ持続的接続HTTPがシンプルに設計され、かつ広く使われているのはこのヘッダが大きな役割をしてるなと感じた。上手く使いこなせるようにまずはどんなヘッダがあるかを知らないとなーと。複数のXMLフォーマットを組み合わせる時に名前の衝突を防ぐHTMLの本当の基本しか書かれていなかったので知ってることが多かった。XMLの名前空間の話とかは見たことあったけどよくわかってなかったので勉強になった。意味論リソースが持つ意味を確定させる人間が読んで解釈するだけでなくプログラムも解釈できるようにする標準化済みのmicroformats(一部)hCalendar:イベント情報hCard:プロフィール情報rel-lisence:ライセンス情報イベントとかよく使うものは標準化しておくとスクレイピングなどするときに統一感があって楽になるって感じなのかな。標準化されててもそれを使うか独自実装するかは個々人の勝手やけど、標準化されたものに従えばWeb世界は整理された綺麗なところになる。ここらへんは知ってるか知らないかで大きく変わるからいろいろ知っておきたい。RSSの標準仕様策定AtomはRSS(ブログ)だけでなく検索エンジンや写真管理など様々使えるAtomのリソースモデルメンバリソースエントリリソースメタデータ:ID、タイトル、著者、更新日時が必須。他には概要説明やカテゴリなど。ArchivingOpenSearchRSSとかでAtomって文字は見たことあったけど、今回初めてきちんと勉強した。拡張もいろいろされていて、広く使われているんだろうなーという印象。便利やとは思うけどどういう時に適しているかまではわからなかったので、一回自分で書くなりして触ってみたいなと感じた。ProtocolAtomを利用したリソース編集プロトコルの規定AtomのエントリーをGETとかPOSTとかできるよーぐらいの理解しかしてない。ブログサービスとかはこういう風にして設計・実装されてるのかなーとか思った。ブーリアン、nullJSONPによるクロスドメイン通信JSONはAPI叩く時に良く見てたし便利だよねって感じ。読み取り専用のWebサービスの設計リソース設計リソース指向アーキテクチャWebサービスで提供するデータの特定データをリソースに分けるリソースにURIで名前をつけるクライアントに提供するリソースの表現を設計するリンクとフォームを利用してリソース同士を結びつけるイベントの標準的なコースを検討するエラーについて検討する郵便番号検索サービスの例をあげて説明されてたのでイメージしやすくわかりやすかった。設計に関しては場数踏むしかないのかなとは思ってるので、本に書かれていたことを意識しながらいろいろ作っていきたいなと思った。ロック楽観的ロックバッチ処理、トランザクション、排他制御まで考えて実装したことがなかったので、大規模なサービスとかエラーが許されないサービスとかだといろいろ考えないといけないんだなと感じた。これらを実現するために特別なプロトコルなどは利用しておらずHTTPのみで実現されているのは凄いなと思った。ここらへんはある程度手法が確立されていてデザインパターンみたいになっているのかなと思うので、そこらへんも勉強していかなきゃなーと感じた。APIを分けて考えない設計手法は様々知っていると適切なカードが切れて将来便利かもしれないと思った。»プロフィールid:mtdtx9通信ネットワークの研究してる大学院生です。解き方メモruby+opencvで画像処理(2値化)2017年2月の振り返り月別アーカイブはてなブログをはじめよう!mtdtx9さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。