WEB道楽

WEB道楽

【日経コンピュータ】電子社印「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)

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

  • 作者:山本 陽平
  • 発売日: 2010/04/08
  • メディア: 単行本(ソフトカバー)

HTTPヘッダの重要性

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

HTTPヘッダの生い立ち

  • HTTP1.0から登場
  • 電子メールのメッセージ仕様のヘッダ形式をもとに追加
    → インターネットの成長とともに規定された歴史
  • HTTP1.0から登場ヘッダと電子メールのメッセージヘッダと共通部分が多い
    例)Content-Type、Dateなど

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

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

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

日時

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通信(SSLTLS)で暗号化するなどの検討が必要
  • 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
    • サーバがクライアントにファイル名を提示
    • 電子メール仕様から伝承
    • 文字エンコーディングが必要

まとめ

【WEBを支える技術】を読む理由 - devdevdevReports

【WEBを支える技術】REST編 - devdevdevReports

【WEBを支える技術】URI仕様編 - devdevdevReports

【WEBを支える技術】URI設計編~良いURI設計とは~ - devdevdevReports

【WEBを支える技術】HTTP基礎編~シンプルさが標準化~ - devdevdevReports

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

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

【日経コンピュータ】アフラックのDX~後編~

アフラックのDX革命~前編~

日経コンピュータの特集に「アフラックのDX革命」が取り上げられましたので、前編を紹介します。

ロボット活用における分身出社

2019年秋 分身ロボット「OriHime」を導入

  • ダイバーシティ推進部が企画
  • 研修場所から離れた地域に住む社員のキャリアアップ支援

「OriHime」とは

orihime.orylab.com

  • オリィ研究所が開発
  • カメラ、マイク、スピーカーが組み込まれている
  • スマートフォンタブレットお専用アプリから遠隔操作できる
  • 遠隔地から映像、音声の確認、発言などが可能

活用方法

  • 細かい動作が可能(手を挙げる、うなずくなど)
  • ビデオ通話よいも親近感のあるコミュニケーション
    (高代公美 東京総合支社支社次長)
  • 集合研修などメイン会場があり、一部が遠隔地の場合に有効
  • 半数以上がリモートの場合は向かない

テレプレゼンスロボット「temi」で日常業務でも導入

「temi」とは

www.robotemi.jp

  • ハウステンボスグループのロボット事業会社「hapirobo st」が販売
  • ディスプレイ、マイク、カメラ、センサーを搭載
  • 自律走行、ビデオ通話が可能

活用方法

  • 介護、育児と仕事を両立支援
  • けがで出社が難しい社員を支援
  • オフィスの雰囲気やメンバーの表情を確かめられる

導入計画

  • 2020年6月 パイロット運用開始
    • 東京在住の管理職が地方都市の拠点で勤務を開始
  • 本格展開
    • 社内での活用に展開
    • 保険代理店などに展開を検討

成果をもたらすアジャイル開発体制

経営環境の変化を察知

従来のプロジェクト

経営環境の変化

  • 異業種のスタートアップ企業が金融サービスに参入
  • 速いスピード感で新しいデジタルサービスを提供
  • 従来のプロジェクト推進では対抗できない

アジャイル開発への切り替え

  • 各業務部門とIT部門が協力してプロジェクト推進する仕組みを構築
  • 2019年1月 アジャイル推進室を立ち上げ
  • 2019年11月 Aflac Agile Baseを新設
  • 透明性、柔軟性を保ち、スピード感ある運営を実現

アジャイル開発体制

3つの組織体制

  • スクワッド
    • プロジェクト開発チーム
    • チーム構成
      • プロダクトオーナー
      • スクラムマスター
      • 業務部門のメンバー
      • IT部門のメンバー
  • チャプター

    • 各部署が担当
    • スクワッドに派遣する業務部門メンバー、IT部門メンバーを選抜
  • トライブ

    • スクワッドを管理
    • スクワッド間の取り組みの方向性の調整

意思決定の権限委譲

  • スクワッドのプロダクトオーナーに権限を委譲
  • 取組みテーマ、予算、意思決定の権限の大半を委譲
  • 迅速な意思決定を実現
  • 意思決定の重さによって待遇を見直し

【日経コンピュータ】アフラックのDX~前編~

アフラックのDX革命~前編~

日経コンピュータの特集に「アフラックのDX革命」が取り上げられましたので、前編を紹介します。

アフラックで起きた51のDXプロジェクト

  • 二見通 CIOが指揮

3つの領域でのDX

顧客・保険代理店

  • 例)ビジュアルIVR
  • 電話とスマホ画面が連動し、顧客体験を一新

社内業務

  • 例)あひるーぺ
  • 社内の情報検索システムにAIを搭載
  • 検索時間を6割削減

マーケティング・営業

  • 例)営業サポートAI
  • 顧客との会話内容をAIがアドバイスなどでサポート

AIスピーカーの開発

企画:音声認識への着目

目的

  • 業務効率化やシステムの利便性向上のため

適用可能性

  • 一般的な会話で利用できる
  • 社内固有の業務用語を予めシステムに登録すれば、認識できる

適用先の課題整理(社内ヘルプデスク)

  • 受付時間
  • 朝から夕方までの担当社員による受付
  • 様々な勤務体系を持つアフラック
  • 早朝出社する社員が利用できない時間帯が存在
  • 混雑
  • 日中は混雑で電話がつながらない

期待する効果

  • 受付時間
  • AIが応答を行うことで24時間対応が可能
  • 混雑
  • AIが応答を行うことで混雑が解消
  • ヘルプデスク担当社員の負荷軽減

開発

アジャイル開発で3か月での稼働を実現

業務直結の効率化

  • 業務利用を念頭にプロトタイプ開発
  • 活用度を高める機能拡張を実現
  • 回答の聞きそびれ、聞き取りづらいなどの課題を発見
  • 応答をスピーカーだけでなく、画面表示やメール送信などの機能追加で解消

3つのポイント

  • UI、UXの実現
  • AIスピーカーでは応答内容を画面表示するUIを採用
  • 適用技術の丁寧に説明
  • ヘルプデスク担当社員に音声認識技術を説明
  • 人を助けるデジタル技術を導入
  • ヘルプデスクをデジタル技術への置き換えではなく、業務負担の軽減と位置付け

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

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

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

  • 作者:山本 陽平
  • 発売日: 2010/04/08
  • メディア: 単行本(ソフトカバー)

HTTPステータスとは

  • サーバーからクライアントにリクエストの結果を返すコード
  • HTTPステータスによってそのあとのクライアントの挙動が変わる
  • 仕様通りにステータスを返すことが重要

ステータスコードの種類

  • 1桁目でどの種類のステータスであるかを判別できる
  • 1xx:処理中
  • 2xx:成功
  • 3xx:リダイレクト
  • 4xx:クライアントエラー
  • 5xx:サーバーエラー

ステータスコードの意味

  • コンポーネント間の結合度を下げる
  • クライアントとサーバーを疎結合にする
  • クライアントの置き換えやサーバーのバージョンアップが行いやすい

エラー処理

プロトコルにあたフォーマットでエラーを返す

  • AtomPubを利用したWebAPIの場合、Atomで返す
  • Jsonを利用したWebAPIの場合、Jsonで返す

Acceptヘッダに応じたフォーマットでエラーを返す

  • クライアントからリクエストで指定

ステータスと結果の整合性

  • ステータスは200(成功)で、レスポンスボディには「File Not Found」となっているなど
  • 人間が理解できても、検索エンジンや機械が解釈を間違う。

【WEBを支える技術】を読む理由 - devdevdevReports

【WEBを支える技術】REST編 - devdevdevReports

【WEBを支える技術】URI仕様編 - devdevdevReports

【WEBを支える技術】URI設計編~良いURI設計とは~ - devdevdevReports

【WEBを支える技術】HTTP基礎編~シンプルさが標準化~ - devdevdevReports

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

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

【日経コンピュータ】電子契約サービスだけじゃない!~請求・支払いのデジタル化と成功のポイント~

電子契約サービスだけじゃない!~請求・支払いのデジタル化と成功のポイント~

日経コンピュータの特集が挑むに「電子契約サービスだけじゃない!~請求・支払いのデジタル化と成功のポイント~」が取り上げられましたので、紹介します。

ハンコだけじゃないテレワークの阻害要因

  • デジタル化が進まない請求書、納品書、検収書への押印、郵送業務
  • 契約時のハンコをなくすだけではテレワークの実現は難しい
  • 見積依頼、回答、請求、支払いなど契約前後もデジタル化が必要

大成建設の事例

  • 「SUPER TRIO」を導入
  • 下請けやグループ企業との取引で利用

2019年の実績

  • 全3万3000件のうち、93%で利用
  • 57%で契約書までをデジタル化

    コロナ禍での課題

  • 取引先の経理部門、法務部門の出社をどう減らすか
  • 大口の取引先だけでなく、小口の取引先企業へも展開

サントリーHDの事例

2020年7月に契約関連の新業務システムを稼働

  • 取引先(卸売業者、小売店、飲食店)との契約から請求、支払いまでをデジタル化し、システムで完結
  • 2022年までに国内のグループ企業へ展開

期待する効果

  • 年間300万枚のかみをさくげん
  • 収入印紙代、印刷代郵送料など年間3000万円のコスト削減
  • 業務効率化によるグループ全体で6万時間の時短効果
  • 2~3年でシステム投資分を回収できる

契約関連のデジタル化の成功ポイント

工程間でのデータ引き継ぎ

  • 見積依頼、回答、契約、請求、支払いなどの工程間でデータ連携
  • 人の手を介さずに書類作成の自動化比率を高める
  • 例)見積依頼時に使用した発注仕様を契約書に反映させるなど

書類のフォーマットを標準化

  • 標準化によって、全社的に書類作成の自動化が進む

社内手続きをデジタル化する

  • 書類の自動チェック、承認などもデジタル化
  • システムにワークフローの機能を持たせるなどが必要

2023年10月に導入される「適格請求書(インボイス)制度」

  • 消費税額の計算に必要な明細を請求書に記録、保存する制度
  • すべての企業でデジタル化すべき事務手続き

仕入税控除額の申告に必要となる

  • 現行では帳簿上のデータから申告できる
  • 2023年から適格請求書を交付し、消費税の積み上げが必要
  • 紙のインボイスでは手作業で計算が必要

各業界で使用するEDIシステムのデータ連携が必要に

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

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

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

  • 作者:山本 陽平
  • 発売日: 2010/04/08
  • メディア: 単行本(ソフトカバー)

HTTPメソッドとは

  • クライアントからサーバーへリソースに対してどのような処理を行うかを伝達する

8つのメソッドと意味

  • GET
    • 子リソースの取得
  • POST 子リソースの作成
    • リソースへのデータ追加
    • どのほかの処理
  • PUT
    • リソースの更新
    • リソースの作成
  • DELETE
    • リソースの作事
  • HEAD
    • リソースのヘッダ取得
  • OPTIONS
    • リソースがサポートするメソッドの取得
  • TRACE
    • 自分宛てにリクエスメッセージを返すテスト
  • CONNECT
    • プロキシ動作のトンネル接続への変更

HTTPメソッドとCRUDの関連

CRUD 意味 HTTPメソッド
Create 作成 POST / PUT
Read 読込 GET
Update 更新 PUT
Delete 削除 DELETE

GET メソッド

  • リソースの取得
  • 例)WEBページの取得、画像の取得、映像の取得など

POST メソッド

  • 子リソースの作成
  • リソースへのデータ追加
  • 他のメソッドでは対応できない処理の代行
    • GETではURIにパラメータが多すぎる場合、代わりにPOSTでリクエストボディにパラメータを入れてデータ取得

PUT メソッド

  • リソースの更新
  • リソースの作成
  • POSTとPUTの使い分け

DELETE メソッド

  • リソースの削除

HEAD メソッド

  • リソースのヘッダを取得
  • Content-Type、文字コードタイプなど

OPTIONS メソッド

  • リソースのサポートするHTTPメソッドを取得
    • Webアプリケーションに実装
    • Apacheに挙動を設定

GETとPOSTだけで実装する場合

  • HTMLのフォームはGETとPOSTだけ使用可能
    • HTMLの制限でGETとPOSTだけを利用する時代が長かった
    • AjaxXMLHttpRequestモジュールで解消
    • 携帯電話(ガラケー)ではサポートしていないので、GETとPOSTのみ
  • _methodパラメータで解決する方法

    • inputタグにパラメータとして含め、サーバー側で受け取る
    • 例)'< input type="hidden" id="_method" value=PUT">'
  • X-HTTP-Method-Overrideで解決する方法

    • リクエストボディにパラメータとして含め、サーバー側で受け取る
    • 例)X-HTTP-Method-Override:PUT

べき等性と安全性

  • べき等性
    • ある操作を何度実行しても結果が同じであること
  • 安全性
    • 操作対象のリソースの状態を変化させないこと
  • GET
    • べき等、安全
  • POST
    • べき等でない、安全でない
  • PUT
    • べき等、安全でない
  • DELETE
    • べき等、安全でない

HTTPメソッド、URIとサーバー側処理の整合性をとる

  • GETでリソース作成、リソースの削除を行ってはならない
  • PUTで相対的な更新を行わない

【WEBを支える技術】を読む理由 - devdevdevReports

【WEBを支える技術】REST編 - devdevdevReports

【WEBを支える技術】URI仕様編 - devdevdevReports

【WEBを支える技術】URI設計編~良いURI設計とは~ - devdevdevReports

【WEBを支える技術】HTTP基礎編~シンプルさが標準化~ - devdevdevReports

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

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