【WEBを支える技術】～RESTを構成する6要素～

Webを支える技術 ―― HTTP，URI，HTML，そしてREST WEB+DB PRESS plus

RESTの全体像

REST全体概要

「REST」の構成要素

①クライアント/サーバー構成

クライアント/サーバー構成

• ①マルチプラットフォーム

  • 様々なハードウェアからのアクセスが可能になる
  • 例）PC、スマートフォン、タブレット、携帯電話など

• ②冗長化

  • リクエストを受付するサーバーを冗長化することで可用性を向上できる
  • 例）アクセス集中に対応、サーバー障害に対応など

• ③④機能分解

  • 開発効率の向上

②ステートレス性

ステートレス性

• ①リクエストのたびにすべての情報を送信

  • クライアント側にメリットはない

• ②クライアントの状態を管理しない

  • 毎回違うサーバーがリクエストを受取可能となり、実装が簡略化
  • レスポンス返却後、リソースを開放可能となり、パフォーマンスが向上
    ※Cookieを使用してセッション管理、認証を行う場合がある

③キャッシュ

キャッシュ

• ①同じリクエストの結果を再利用する

  • サーバーとクライアント間の通信料を低減できる
  • ネットワーク帯域の利用、処理時間を短縮し、パフォーマンスを向上できる
  • 古いキャッシュデータによって情報の信頼性が低下する可能性がある

• ②クライアントに再利用可能かを伝達

  • 有効期限などキャッシュ可能な条件も伝達

④統一インターフェース

統一インターフェース

• ①使用可能な8つのHTTPメソッド
  • RESTの代表的な特徴
  • リソースに対する操作を限定する
  • サーバーとクライアントの独立性が向上し、マルチプラットフォームに対応しやすくなる

⑤階層化システム

階層化システム

• ①クライアントはサーバ構成を意識せず、リクエストを送信

  • サーバー構成を変更してもクライアントには影響がない（クライアントはサーバ構成がわからない）
  • オブジェクト指向のカプセル化と同じ性質

• ②サーバ側のアーキテクチャを階層的に分離

  • サーバ間の通信はHTTP通信のため、さらなるサーバ構成変更などの拡張性が高い

⑥コードオンデマンド

コードオンデマンド

• ①サーバにプログラムを保持

  • JavaScript、Flashのプログラムを保持
  • サーバ側の変更のみで機能追加が可能となり、拡張性が高い
    ※スマホアプリなどはクライアントアプリの更新が必要な場合がある

• ②ダウンロードしたプログラムをそのまま実行

  • 通信の意味がJavaScriptのプログラムに依存し、HTTPのプロトコルの可視性が下がる

【Maven・gradle】～全体概要～

開発ツールとの関係図（eclipse上で動作させる）

eclipse

OSとの関係図（Windows上で動作させる）

Windows

ビルドツールとは

• 開発効率化を支援するツール
• 手作業では大変な開発のライフサイクルを自動化する

役割

• ①プログラムのビルド
• ②テストの実行
• ③ライブラリの管理
• ④デプロイ

開発言語との関係

• 開発言語と親和性が必要
• ツール内で実行される処理も文法を持った言語で記述
• Java　→　Java仮想マシンで動作するビルドツール

開発ツールとビルドツールの関係

• 開発ツールにはビルドツールを組み込める
• EclipseにはMaven、Gradleをプラグインでき、JVM上で実行できる
• 開発ツール内部からコマンドを実行する
• ビルドツール単体でも実行可能
• JVM、Mavenのインストールが必要

Javaビルドツール入門　Maven/Gradle/SBT/Bazel対応 [ 掌田津耶乃 ] 価格：3080円（税込、送料無料) (2020/10/30時点) 楽天で購入

【WEBを支える技術】～全体概要～

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

全体概要図

全体概要

「WEBを支える技術」で学べる要素

①REST

• RESTを構成する６つのアーキテクチャをそれぞれ解説

②URI

• URIの基本仕様の解説
• 良いURI設計のポイントを解説

③HTTPの基本

• HTTPの歴史、基本仕様を開設

④HTTPメソッド

• 8つのHTTPメソッドの解説
• HTTPメソッドの使い分けと設計

⑤HTTPステータス

• HTTPステータスの種類と意味の解説
• HTTPステータスの使い分けと設計

⑥HTTPヘッダ

• HTTPヘッダと電子メールの歴史と基本仕様の解説
• HTTPヘッダとHTTPメソッド、HTTPステータスの組み合わせた設計の解説

⑦ハイパーメディア

• HTMLの解説
• microformatsの解説
• Atomの解説
• Atom Publishing Protocolの解説
• JSONの解説

⑧WEBサービス設計

• リソース設計の概要解説
• 読取専用のWEBサービスのリソース設計のハンズオン
• 書き込みありのWEBサービスのリソース設計のハンズオン

【日経コンピュータ】電子契約サービスの普及～弁護士ドットコムの挑戦～

電子契約サービスの普及～弁護士ドットコムの挑戦～

日経コンピュータの挑戦者に「電子契約サービスの普及～弁護士ドットコムの挑戦～」が取り上げられましたので、紹介します。

挑戦者

• 橘大地氏
• 弁護士ドットコム　クラウドサイン事業部長

経歴

• 東京大学法科大学院修了
• サイバーエージェント社内弁護士
• GVA法律事務所
• 弁護士ドットコム

新型コロナ禍で注目される電子契約サービス

• 電子的な文書によって契約を完結
• 契約当事者に代わり、サービス事業者が電子署名することで契約を担保
• 国内では弁護士ドットコムのクラウドサインが圧倒的なシェアを持つ

商業・法人登記での認可が普及が加速

2020年5月の内閣府規制改革推進会議で要望

• クラウドサイン8万社の利用実績をもとに電子契約にまつわる規制緩和を訴求
• 商業・法人登記における規制緩和を強く要望

2020年6月に認可

• 法務省の商業・法人登記におけるオンライン申請
• 電子契約サービスの電子署名を付けた文書を利用可能
• 他社の電子契約サービスも利用可能に

期待する効果

• 従来は取締役全員の電子証明書の準備が必要
• オンライン申請に必要な準備の手間と時間が大幅に削減
• 法的有効性を払拭できるため、電子契約サービスの普及が加速

普及を阻む2つの壁

法律の壁

20年改正されていない電子署名法

• 2001年に施行
• 電子契約サービスで必須となる電子署名について制定
• 当事者同士の電子署名のみを想定
• サービス事業者が代行で電子署名することを想定していない

導入企業の法務部からストップがかかる事例

• 導入企業の事業部へは提案がうまくいくことが多い
• 電子署名法に準拠していない理由で失注

商習慣の壁

根付いていたハンコ文化

• 慣れている紙と印鑑を希望する企業も少なくない

導入企業の周りへの理解

• 導入企業への説得
• 取引先企業への説得

乗り越えた壁

弁護士の強みを活かした説明

• 電子署名法に準拠しなくても契約の有効性を担保可能であることを説明
• 1社1社の顧客に粘り強く説明
• 電子契約サービスが世界的に広がっている実情を説明
• デジタル時代に利便性の高い電子契約を採用すべきことを説明

結果

• ベンチャー企業を中心に利用企業を拡大
• 野村証券、サントリーホールディングスなどの大手企業も導入

今後の展望と想い

生活をより便利なものへしていきたい

• 個人への普及がカギ

日本発のサービスを世界へ輸出

• 世界的にも普及していない
• 日本が世界トップの電子契約社会になる可能性もある
• 日本社会の変革を目指す

【日経コンピュータ】富士通、アジャイルフレームワーク導入支援へ

富士通、アジャイルフレームワーク導入支援へ

日経コンピュータのニュースに「富士通、アジャイルフレームワーク導入支援へ」が取り上げられましたので、紹介します。

2020年6月 富士通が米スケールド・アジャイルとパートナー契約を締結

• スケールド・アジャイルフレームワーク（SAFe）の開発元
• 大規模システム開発向けアジャイルフレームワーク
• 世界的に普及しているフレームワークの1つ
• 経営や事業変革によって、経営スピードの向上が主眼
• 企画、業務部門、IT部門が協力してアジャイル開発を進める方式

SAFeとパートナー契約した富士通の狙い

• DX事業を推進していきたい
• DXで経営スピードの向上は図り、経営とITの連動で企業全体の変革を目指す
• アジャイル開発の知見は蓄積したが、経営スピードのノウハウは薄い
• SAFeの特徴であるとマッチする

資格保持者を増やし、導入支援を拡大へ

SAFe導入支援の認定資格（SPC）の保持者を増やす計画（現在：28人）

• 研修プログラムの作成など

先行するNTTデータ

• 2017年にパートナー契約を締結
• 現在のSPC保持者：60人
• 2021年までに100人を目指す

さらに先行している北米

• 2017年ごろからアジャイルフレームワークが浸透
• これまでに日本ではアジャイル開発は浸透してきた
• 今後は経営スピード向上を目指すアジャイル手法が普及する見込み

【日経コンピュータ】電子社印「eシール」制度化へ～EU手本にGMOなどが先行～

電子社印「eシール」制度化へ～EU手本にGMOなどが先行～

日経コンピュータのニュースに「電子社印「eシール」制度化へ～EU手本にGMOなどが先行～」が取り上げられましたので、紹介します。

社印（角印）とは

概要

• 企業が発行する請求書、領収書に広く使用されている
• 企業が使う認印的な存在

社印（角印）の欠点

• 書類にハンコを押印するため、印刷、封入、郵送などの手間がかかる
• 新型コロナウイルスの感染拡大防止のために電子化のニーズが高まっている

社印の代替になる「eシール」とは

• 社印の電子版、電子署名の企業版の位置づけ
• 自社で作成したPDFなどの電子文書にeシールを付与する
• データの信頼性を確保する仕組みである「トラストサービス」の1つ

「eシール」の2つの機能

• 文書を作成したのは自社であることの証明
• 文書は作成後に改ざんされていないことを証明

必要となる法整備

既に実用化しているEU

• 「eIDAS（イーアイダス）規則」という法制度に基づき、実用化

日本での法整備

• 日本では法規制がない
• 2020年4月に総務省が検討会を立ち上げ
• ベンダー関係者、有識者が出席し、制度設計を検討

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)

HTTPヘッダの重要性

• メッセージボディに対する付加的な情報（メタデータ）を表現
• クライアントとサーバはヘッダを見てメッセージに対する挙動を決定する
• メディアタイプなや言語タグなど、アプリケーションのフレームワークでなく、実装者が設定するヘッダも多い

HTTPヘッダの生い立ち

• HTTP1.0から登場
• 電子メールのメッセージ仕様のヘッダ形式をもとに追加
  →　インターネットの成長とともに規定された歴史

• HTTP1.0から登場ヘッダと電子メールのメッセージヘッダと共通部分が多い
  例）Content-Type、Dateなど

• 歴史からくる制約、バッドノウハウも多い

  • メール：7bit ASCIIコード以外の文字が入れられない
  • HTTP：文字エンコーディングの制限でラテンアルファベット以外い入れられない

• 電子メールとの違い

  • メール
    • 1方向にしかメッセージのやり取りができない
  • HTTP
    • 一度の通信でリクエスト/レスポンスの2つのメッセージをやりとり

日時

• DateやExpiresが該当
• HTTPではすべてグリニッジ標準時で表現　→　サマータイムなどに対応
• メールではタイムゾーン付きの書式を許可

MIMEメディアタイプ

• メッセージでやり取りするリソースの表現の種類を指定

• 電子メールからきた仕様（Muktipurpose Internet Mail Extensions）

• Content-Type

  • メディアタイプを指定する
  • タイプとサブタイプで構成

• charsetパラメータ

  • 文字エンコーディングを指定する。
  • タイプがtextの場合、デフォルトがISO8859-1のため日本語だと文字化けする。
  • xmlの場合だと、xmlの中に文字コードを定義してもHTTPヘッダで定義しておかないと、文字化けしてしまう
  • 必ずcharsetパラメータを定義したほうがいい。

言語タグ

• Content-Language
  • リソース表現の自然言語を指定する
  • ISO639で定義された言語コードとISO3166で定義された地域コードを指定
    例）「ja-JP」

コンテントネゴシエーション

• メディアタイプ、文字エンコーディング、言語タグはサーバーで指定

• クライアントと交渉して決めることができるパラメータ

• Accept

  • 処理できるメディアタイプを伝える
  • メディアタイプに優先順位をつける
  • サーバーがクライアントからの要求にこたえられない場合、「406：Not Acceptable」

• Accept-Charset

  • 処理できる文字エンコーディングを伝える
  • 文字コードに優先順位をつける

• Accept-Language

  • 処理できる言語を伝える
  • 自然言語に優先順位をつける

Content-Lengthとチャンク転送

• Content-Length

  • ボディの長さを指定する
  • 静的ファイルなどあらかじめサイズがわかっている場合

• Transfer-Encoding:chunked

  • チャンク転送
  • ボディを分割して転送する。
  • 動的に画像生成する場合など、ファイルサイズが決まるまでレスポンスが返せない場合に応答性能が低下するのを防ぐ
  • チャンクサイズは16進数を仕様
  • HTTP1.1で受信が必須仕様

認証

• HTTP認証方式

  • リソースへのアクセス制御がかかっている場合のクライアントへの認証情報通知
  • ステータスコード
    • 401 Unauthorized
    • このリソースに対してのアクセスには認証が必要
  • WWW-Authenticateヘッダ
    • 認証方式
    • URI空間
      　→URI中にあるパス以下のコト
    • 同じURI空間に属するリソースには同じ認証情報を送信できる

• HTTPS

  • HTTP、SSL/TLSを組み合わせた通信の総称
  • 通信路を暗号化して通信データを保護し、盗聴を防ぐ目的で利用する
    • 暗号化
    • 認証
    • 改ざん検知

• Basic認証

  • ユーザー名とパスワードをAuthorizationに入れれてリクエスト
  • ユーザー名とパスワードは「:」で連結し、Base64エンコーディング
  • 簡単にデコード可能なので、平文がネットワーク上に流れている
  • 許容されるセキュリティ強度か、HTTPS通信（SSL、TLS）で暗号化するなどの検討が必要

• Digest認証

  • セキュアな認証方式
  • 認証なしでリクエストして、レスポンス情報から認証情報を生成し、再送信する

  • チャレンジ

    • リクエスト
      • 認証情報なし
    • レスポンス

      • nonce

        • number used once
        • リクエストごとに変化する文字列
        • タイムスタンプ、パスワード（サーバーのみが知りえる情報）などから生成
        • 有効期間を狭めるためにタイムスタンプを活用

      • qop

        • quality of protection
        • 「auth」 or 「auth-init」が指定
        • クライアントのメッセージダイジェスト作成方法に影響あり
        • auth：メソッドとURIからメッセージダイジェストを作成
        • auth-init：メソッドとURI、メッセージボディからメッセージダイジェストを作成
        • POSTやPUTの場合、メッセージ全体が改ざんされていないことを保証

      • opaque

        • クライアントが推測できない文字列
        • URI空間ごとに共通

  • 再送信

    • ①ユーザー名、realm、パスワードパスワードを「:」で連結し、MD5ハッシュ値を求める
    • ②メソッドとURIのパスを「:」で連結し、MD5ハッシュ値を求める
    • ③①、サーバーから得たnonce、クライアントかがnonceを送った回数、クライアントが生成したnonce、qopの値を「:」で連結し、MD5ハッシュ値を求める
      • リクエストのHTTPヘッダのresponseに③を入れて、再送信する

  • 利点

    • パスワードに関するセキュリティリスクを低減
      • パスワードを盗まれる危険性がない
      • パスワードそのものを預けなくてもよい、パスワードのハッシュ値を保管すだけ

  • 欠点

    • パスワード以外のセキュリティリスクは回避できない
      • パスワードのみを暗号化
      • メッセージ自体は平文でネットワーク上に流れる
    • クライアント側の負担が大きい
      • 同じURI空間でも毎回チャレンジして、ダイジェストを生成する必要がある
        （nonceを取得するため）

  • 普及していない理由

    • クライアント側の負担が大きい
    • ApacheなどのWEBサーバーではDigest認証がオプション扱い
    • ホスティングサービスではサポートされていない可能性が高い
    • 自前で用意する場合もセキュリティ上の問題でApacheがヘッダーを渡してくれないため、Digest認証を利用できない

• WSSE

  • HTTP1.1の標準外の認証方式
  • AtomPubやWEBAPIの認証で利用
  • Basic認証やDigest認証が利用できない場合にパスワードをネットワーク上に 流さずに認証するために誕生
  • WS-SecurityのUsernameTokenがベース

  • 方式

    • クライアント側

      • クライアントが認証情報なしでリクエスト
      • クライアントがリクエストを再送信
      • AuthorizationヘッダにWSSE、profileにサーバから受け取ったUsernameTokenを設定
      • X-WSSEにパスワードダイジェスト、nonce、日時情報を設定

    • サーバー側

      • サーバーが401　Unauthorizedを返却
      • WWW-Authenticateにprofileを設定（UsernameToken）
      • サーバーがクライアントのパスワードダイジェストと比較して認証

  • サーバー側でパスワードを保存する必要がある

  • パスワードがネットワーク上に流れることはない
  • Basic認証とDigest認証の中間

キャッシュ

• サーバから取得したリソースをローカルストレージに蓄積し、再利用する手法

• ローカルストレージにキャッシュしたデータそのものをキャッシュと呼ぶこともある

• ヘッダ（サーバーへのアクセスをしない）

  • 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からの追加機能

• 問題

  • リクエストレスポンスのたびにTCPコネクションの確立、切断を繰り返していた
    　→処理が重くなっていた。画像や外部ファイルが多いWebページだととくに

• 解決

  • 都度接続、切断を繰り返すのではなく、接続し続ける手法が開発
  • 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

【WEBを支える技術】HTTPメソッド編～名は体を表す～ - devdevdevReports

【WEBを支える技術】HTTPステータス編～名は体を表す～ - devdevdevReports