【WEBを支える技術】～RESTを構成する6要素～
RESTの全体像
「REST」の構成要素
①クライアント/サーバー構成
②冗長化
③④機能分解
- 開発効率の向上
②ステートレス性
①リクエストのたびにすべての情報を送信
- クライアント側にメリットはない
②クライアントの状態を管理しない
③キャッシュ
①同じリクエストの結果を再利用する
- サーバーとクライアント間の通信料を低減できる
- ネットワーク帯域の利用、処理時間を短縮し、パフォーマンスを向上できる
- 古いキャッシュデータによって情報の信頼性が低下する可能性がある
②クライアントに再利用可能かを伝達
- 有効期限などキャッシュ可能な条件も伝達
④統一インターフェース
- ①使用可能な8つのHTTPメソッド
- RESTの代表的な特徴
- リソースに対する操作を限定する
- サーバーとクライアントの独立性が向上し、マルチプラットフォームに対応しやすくなる
⑤階層化システム
⑥コードオンデマンド
①サーバにプログラムを保持
- JavaScript、Flashのプログラムを保持
- サーバ側の変更のみで機能追加が可能となり、拡張性が高い
※スマホアプリなどはクライアントアプリの更新が必要な場合がある
②ダウンロードしたプログラムをそのまま実行
- 通信の意味がJavaScriptのプログラムに依存し、HTTPのプロトコルの可視性が下がる
![[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]](https://hbb.afl.rakuten.co.jp/hgb/1d78a389.591d5956.1d78a38a.e928a4f5/?me_id=1213310&item_id=18375048&pc=https%3A%2F%2Fthumbnail.image.rakuten.co.jp%2F%400_mall%2Fbook%2Fcabinet%2F9380%2F9784798049380.jpg%3F_ex%3D240x240&s=240x240&t=picttext "[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]")
【WEBを支える技術】～全体概要～
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
- 作者:山本 陽平
- 発売日: 2010/04/08
- メディア: 単行本（ソフトカバー）
全体概要図
「WEBを支える技術」で学べる要素
①REST
- RESTを構成する６つのアーキテクチャをそれぞれ解説
②URI
③HTTPの基本
- HTTPの歴史、基本仕様を開設
④HTTPメソッド
- 8つのHTTPメソッドの解説
- HTTPメソッドの使い分けと設計
⑤HTTPステータス
- HTTPステータスの種類と意味の解説
- HTTPステータスの使い分けと設計
⑥HTTPヘッダ
- HTTPヘッダと電子メールの歴史と基本仕様の解説
- HTTPヘッダとHTTPメソッド、HTTPステータスの組み合わせた設計の解説
⑦ハイパーメディア
- HTMLの解説
- microformatsの解説
- Atomの解説
- Atom Publishing Protocolの解説
- JSONの解説
⑧WEBサービス設計
【日経コンピュータ】電子契約サービスの普及～弁護士ドットコムの挑戦～
電子契約サービスの普及～弁護士ドットコムの挑戦～
日経コンピュータの挑戦者に「電子契約サービスの普及～弁護士ドットコムの挑戦～」が取り上げられましたので、紹介します。
挑戦者
- 橘大地氏
- 弁護士ドットコム クラウドサイン事業部長
経歴
- 東京大学法科大学院修了
- サイバーエージェント社内弁護士
- GVA法律事務所
- 弁護士ドットコム
新型コロナ禍で注目される電子契約サービス
商業・法人登記での認可が普及が加速
2020年5月の内閣府規制改革推進会議で要望
2020年6月に認可
期待する効果
- 従来は取締役全員の電子証明書の準備が必要
- オンライン申請に必要な準備の手間と時間が大幅に削減
- 法的有効性を払拭できるため、電子契約サービスの普及が加速
普及を阻む2つの壁
法律の壁
20年改正されていない電子署名法
導入企業の法務部からストップがかかる事例
- 導入企業の事業部へは提案がうまくいくことが多い
- 電子署名法に準拠していない理由で失注
商習慣の壁
根付いていたハンコ文化
- 慣れている紙と印鑑を希望する企業も少なくない
導入企業の周りへの理解
- 導入企業への説得
- 取引先企業への説得
乗り越えた壁
弁護士の強みを活かした説明
- 電子署名法に準拠しなくても契約の有効性を担保可能であることを説明
- 1社1社の顧客に粘り強く説明
- 電子契約サービスが世界的に広がっている実情を説明
- デジタル時代に利便性の高い電子契約を採用すべきことを説明
結果
- ベンチャー企業を中心に利用企業を拡大
- 野村証券、サントリーホールディングスなどの大手企業も導入
今後の展望と想い
生活をより便利なものへしていきたい
- 個人への普及がカギ
日本発のサービスを世界へ輸出
- 世界的にも普及していない
- 日本が世界トップの電子契約社会になる可能性もある
- 日本社会の変革を目指す
【日経コンピュータ】富士通、アジャイルフレームワーク導入支援へ
日経コンピュータのニュースに「富士通、アジャイルフレームワーク導入支援へ」が取り上げられましたので、紹介します。
2020年6月 富士通が米スケールド・アジャイルとパートナー契約を締結
- スケールド・アジャイルフレームワーク（SAFe）の開発元
- 大規模システム開発向けアジャイルフレームワーク
- 世界的に普及しているフレームワークの1つ
- 経営や事業変革によって、経営スピードの向上が主眼
- 企画、業務部門、IT部門が協力してアジャイル開発を進める方式
SAFeとパートナー契約した富士通の狙い
- DX事業を推進していきたい
- DXで経営スピードの向上は図り、経営とITの連動で企業全体の変革を目指す
- アジャイル開発の知見は蓄積したが、経営スピードのノウハウは薄い
- SAFeの特徴であるとマッチする
資格保持者を増やし、導入支援を拡大へ
SAFe導入支援の認定資格（SPC）の保持者を増やす計画（現在：28人）
- 研修プログラムの作成など
先行するNTTデータ
- 2017年にパートナー契約を締結
- 現在のSPC保持者：60人
- 2021年までに100人を目指す
さらに先行している北米
【日経コンピュータ】電子社印「eシール」制度化へ～EU手本にGMOなどが先行～
日経コンピュータのニュースに「電子社印「eシール」制度化へ～EU手本にGMOなどが先行～」が取り上げられましたので、紹介します。
社印（角印）とは
概要
- 企業が発行する請求書、領収書に広く使用されている
- 企業が使う認印的な存在
社印（角印）の欠点
- 書類にハンコを押印するため、印刷、封入、郵送などの手間がかかる
- 新型コロナウイルスの感染拡大防止のために電子化のニーズが高まっている
社印の代替になる「eシール」とは
- 社印の電子版、電子署名の企業版の位置づけ
- 自社で作成したPDFなどの電子文書にeシールを付与する
- データの信頼性を確保する仕組みである「トラストサービス」の1つ
「eシール」の2つの機能
- 文書を作成したのは自社であることの証明
- 文書は作成後に改ざんされていないことを証明
必要となる法整備
既に実用化しているEU
- 「eIDAS（イーアイダス）規則」という法制度に基づき、実用化
日本での法整備
eシール事業進出を発表した2つの事業者
GMOグローバルサイン
- 電子認証サービスを手掛ける企業
- 2020年6月に日本版eシール対応のサービス設計、開発の開始を発表
- 総務省での検討を踏まえて日本版eシール対応サービスを提供
帝国データバンク
- 企業調査情報を提供する企業
- 2020年6月に日本版eシール対応のサービス設計、開発の開始を発表
- 同社が公表する企業調査情報の改ざん防止に使用する予定
- 電子認証サービス会社との連携も視野
自治体も動き出した
2020年7月に福岡県飯塚市が実証事業を2021年に実施することを発表
住民が遠隔地から各種証明書をスマホアプリで受け取れるサービス
- 住民票などの各種証明書データに独自のeシールやタイムスタンプを付与
- データの作成時刻やデータの改ざんがないことを証明
期待するサービスの効果
- 窓口交付の多い住民票のリモート化による業務効率化
- 住民票以外の課税証明書など他の証明書への拡大を期待
- 飯塚市が発行した証明書を企業などが確認、保存利用する社会実装を目指す
【WEBを支える技術】HTTPヘッダ編～～
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
- 作者:山本 陽平
- 発売日: 2010/04/08
- メディア: 単行本（ソフトカバー）
- HTTPヘッダの重要性
- HTTPヘッダの生い立ち
- 日時
- MIMEメディアタイプ
- 言語タグ
- コンテントネゴシエーション
- Content-Lengthとチャンク転送
- 認証
- キャッシュ
- 持続的接続
- その他のHTTPヘッダ
- まとめ
HTTPヘッダの重要性
- メッセージボディに対する付加的な情報（メタデータ）を表現
- クライアントとサーバはヘッダを見てメッセージに対する挙動を決定する
- メディアタイプなや言語タグなど、アプリケーションのフレームワークでなく、実装者が設定するヘッダも多い
HTTPヘッダの生い立ち
- HTTP1.0から登場
- 電子メールのメッセージ仕様のヘッダ形式をもとに追加
→ インターネットの成長とともに規定された歴史 HTTP1.0から登場ヘッダと電子メールのメッセージヘッダと共通部分が多い
例）Content-Type、Dateなど歴史からくる制約、バッドノウハウも多い
- メール：7bit ASCIIコード以外の文字が入れられない
- HTTP：文字エンコーディングの制限でラテンアルファベット以外い入れられない
電子メールとの違い
- メール
- 1方向にしかメッセージのやり取りができない
- HTTP
- 一度の通信でリクエスト/レスポンスの2つのメッセージをやりとり
- メール
日時
MIMEメディアタイプ
- メッセージでやり取りするリソースの表現の種類を指定
電子メールからきた仕様（Muktipurpose Internet Mail Extensions）
Content-Type
- メディアタイプを指定する
- タイプとサブタイプで構成
charsetパラメータ
言語タグ
コンテントネゴシエーション
- メディアタイプ、文字エンコーディング、言語タグはサーバーで指定
クライアントと交渉して決めることができるパラメータ
Accept
- 処理できるメディアタイプを伝える
- メディアタイプに優先順位をつける
- サーバーがクライアントからの要求にこたえられない場合、「406：Not Acceptable」
Accept-Charset
Accept-Language
- 処理できる言語を伝える
- 自然言語に優先順位をつける
Content-Lengthとチャンク転送
Content-Length
- ボディの長さを指定する
- 静的ファイルなどあらかじめサイズがわかっている場合
Transfer-Encoding:chunked
- チャンク転送
- ボディを分割して転送する。
- 動的に画像生成する場合など、ファイルサイズが決まるまでレスポンスが返せない場合に応答性能が低下するのを防ぐ
- チャンクサイズは16進数を仕様
- HTTP1.1で受信が必須仕様
認証
HTTP認証方式
Digest認証
- セキュアな認証方式
- 認証なしでリクエストして、レスポンス情報から認証情報を生成し、再送信する
チャレンジ
再送信
利点
- パスワードに関するセキュリティリスクを低減
- パスワードを盗まれる危険性がない
- パスワードそのものを預けなくてもよい、パスワードのハッシュ値を保管すだけ
- パスワードに関するセキュリティリスクを低減
欠点
- パスワード以外のセキュリティリスクは回避できない
- パスワードのみを暗号化
- メッセージ自体は平文でネットワーク上に流れる
- クライアント側の負担が大きい
- 同じURI空間でも毎回チャレンジして、ダイジェストを生成する必要がある
（nonceを取得するため）
- 同じURI空間でも毎回チャレンジして、ダイジェストを生成する必要がある
- パスワード以外のセキュリティリスクは回避できない
普及していない理由
WSSE
キャッシュ
- サーバから取得したリソースをローカルストレージに蓄積し、再利用する手法
ローカルストレージにキャッシュしたデータそのものをキャッシュと呼ぶこともある
ヘッダ（サーバーへのアクセスをしない）
Pragma
- キャッシュを抑制
- 「no-cache」のみ指定可能
- 指定された場合は必ずサーバーにアクセスする
- キャッシュを抑制させない場合に指定（Cache-Controlにも指定）
Expires
- キャッシュの有効期限を示す
- クライアントが有効期限内からサーバーへのアクセスを行うか判断する
- 最長1年を推奨
- 有効期限が明確に決まっている場合に指定
Chache-Control
- 詳細なキャッシュ方法を指定する
- HTTP1.1で追加、Pragma、Expiresを代用可能
- 相対的な有効期限設定が可能
- 有効期限が相対的に指定したい場合に指定
条件付きGET
- サーバーに判断してもらう
クライアントではキャッシュ利用不可と判断された場合でもリクエストヘッダに情報を詰めて、キャッシュ利用可否をサーバーに判断してもらう
if-Modified-Since
- リソースの更新日時を条件にする
if-Non-Match
- リソースのEtagを条件にする
- サーバーがEtagを出している場合に利用、正確な更新有無が判断可能
静的ファイルの場合
- Webサーバーで判断可能
- inode番号、ファイルサイズ、更新日時から自動計算可能
動的リソースの場合
- アプリケーションで判断する
- 生成したHTMLなどからEtagを算出
- サイズが大きなリソースや複雑なクエリが発生する場合はメタデータで生成、リソースの更新カウンタから算出
持続的接続
- HTTP1.1からの追加機能
問題
解決
- 都度接続、切断を繰り返すのではなく、接続し続ける手法が開発
- HTTP1.0ではオプション（keep-alive）
- HTTP1.1ではデフォルト
- パイプライン化
- クライアントはサーバからのレスポンスを待たずに同じサーバーにリクエストを送信可能
- コネクションを切断したい場合、（Connection:close）を指定
その他のHTTPヘッダ
- Content-Disposition
- サーバがクライアントにファイル名を提示
- 電子メール仕様から伝承
- 文字エンコーディングが必要
まとめ
- HTTPヘッダはメソッドやステータスコードと組み合わせて認証やキャッシュなどのHTTPの重要な機能を実装
- 電子メールや文字エンコーディングは深い歴史があり、バッドノウハウを引き継いでいる。
- HTTPヘッダをうまく利用するためにサーバやブラウザだけでなく、電子メールや文字エンコーディングの歴史も調査する必要がある
【WEBを支える技術】を読む理由 - devdevdevReports
【WEBを支える技術】REST編 - devdevdevReports
【WEBを支える技術】URI仕様編 - devdevdevReports
【WEBを支える技術】URI設計編～良いURI設計とは～ - devdevdevReports
【WEBを支える技術】HTTP基礎編～シンプルさが標準化～ - devdevdevReports