ぼちぼちクラウド

クラウド系SEのぼちぼち技術ブログ

【読書記録】Webを支える技術　第4部

第4部の構成

HTML

  • 見出しや段落などの構造を定義した文書フォーマット

microformats

  • HTMLに比べ、WebAPIをプログラム用に別途用意する必要がない、メンテナンス性などの面ですぐれている

Atom

Atom Publishing Protocol(AtomPub)

  • Atomはデータフォーマットの規定であるのに対し、AtomPubはAtomを利用したリソース編集(CRUD操作)プロトコル
  • ブログや検索データベースには向いているが、リアルタイム性が重要なAPI、データの階層構造が重要なAPIなどには向いていない

JSON

  • 上記のXML系のリソース表現と異なり、データを表現するフォーマット

※都合上、現時点では「HTML」「JSON」のみまとめさせていただきます

第10章　HTML

HTMLのメディアタイプ

  • 2種類存在する
text-html
  • SGMLベースのHTML
application/xhtml*xml

XMLの仕様

  • 木構造となっており、要素(headなど)を入れ子にして表現する
  • 先頭にXMLであることを宣言する

　

HTMLの構成

  • ヘッダとボディから構成される
ヘッダ
ボディ
  • 文書の内容そのもの
  • ブロックレベル要素：段落や見出しなど大きなかたまり
  • インライン要素：ブロックレベル要素の中に入る、強調や改行・画像埋め込みなど

リンク

要素(アンカー)
  • ブロック要素の中でほかのWebページにリンクするためのタグ
  • HTMLのヘッダでWebページの関係を指定する
要素、要素
  • 画像埋め込み、その他要素(動画など)の埋め込み
フォーム
  • リンク先のURIにGETとPOSTが発行できる

　

　

rel属性


第14章　JSON

JSONとは

  • データを表現するフォーマット
  • JavaScript記法。多くのプログラミング言語がライブラリを用意しており、言語間でデータを受け渡すことが容易

メディアタイプ

  • application/json
  • UTF-8,16,32のいずれかでエンコードするルール
  • UTF-8でエンコードしたJSONの場合

　Content-Type: application/json; charset=utf-8

使用可能なデータ型

  1. オブジェクト：名前と値の集合(メンバと呼ぶ)。メンバの名前は常に文字列。値は下記いずれも使える
  2. 配列
  3. 文字列
  4. 数値
  5. ブーリアン
  6. null

{
"name": "Yamada",
"age":34,
"interests":["web","xml","rest"].
"address":{"pref": "tokyo" , "region":"shinjuku"}
}

JSONPによるクロスドメイン通信

  • JSON with Paddingの略
クロスドメイン通信とは
  • 不特定多数のドメインに属するサーバにアクセスすること
  • AjaxではJavaScriptがあるサーバと別のサーバとは通信できない
  • 実際にはサービス構成上、ほかのサーバのWebAPIと通信が必要になるシチュエーションもある(地図データなど)
script要素による解決方法
  • script要素はブラウザのセキュリティ制限を受けない
  • JSONPではJSONを関数名でラップし、ドメインの異なるサーバからデータを取得する

　

  • 上記をレンダリングするとJSONPのURIを自動的にGETし、JSONをサーバ側で読み取ることができる

【読書記録】Webを支える技術　第3部③

第9章　HTTPヘッダ

HTTPヘッダの意義

  • ヘッダにはメッセージのメタデータが設定されている
  • クライアントやサーバはヘッダを見てメッセージに対する挙動を決定する
  • 認証やキャッシュの機能は、ヘッダをメソッドやステータスコードと組み合わせて実現されている

HTTPヘッダの歴史

メールと共通しているヘッダがある
  • Content-Type、Dateなど
  • HTTPヘッダの仕様は電子メールのメッセージ仕様をもとに定義されたため
  • メールとHTTPで異なる点は、HTTPは双方向通信・メールは単一方向の通信であること
  • そのため、HTTPでは電子メールにはないヘッダも存在する

日時ヘッダ

  • 例：Date、Expires
  • GMT形式で表現
  • 例) Date:Tue, 06 Jul 2010 03:21:05 GMT

MIMEメディアタイプ

  • リソースの表現の種類を指定
Content-Type
  • 例) Content-Type:application.xhtml+xml; charset=utf-8
  • 「application/xhtml+xml」がメディアタイプ
    • タイプ：application（画像、音声、映像、テキスト以外）
    • サブタイプ：xhtml+xml（XMLであることを示す）
  • charsetパラメータは、XHTML文書をUTF-8でエンコードしていることを示す

言語指定ヘッダ

  • Content-Languageの値は「言語タグ」と呼ばれる
  • 例)Content-Language; ja-JP

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

クライアントとサーバが交渉してメディアタイプや文字エンコード、言語タグを決めることもできる
  • Acceptヘッダ
  • Accept-Charsetヘッダ
  • Accept-Languageヘッダ

Content-Length

  • メッセージにボディがある場合、そのサイズを10進数のバイトで示す
  • 例)Content-Length:5538

チャンク転送

  • 動的に画像を生成するようなWebサービスの場合、ファイルサイズが決まる前からレスポンスを少しずつ転送できる
  • 例) Transfer-Encoding: chunked

認証

Basic認証
  • ユーザ名とパスワードによる認証方式
  • ユーザ名とパスワードを「:」で連結しBase64でエンコード(※)した文字列をAuthorizationヘッダに設定
  • ※データを64種類の文字列で表現するエンコーディング方式
  • HTTPSで通信路上での暗号化を推奨
Digest認証
  • メッセージにハッシュ関数を適用した結果のハッシュ値を用いる
  • 認証情報なしでまずリクエストを送信し、返ってきたチャレンジを使って次回のリクエストを組み立てる
  • 認証に必要な情報が得られたら、ユーザ名とパスワードを使ってダイジェストを生成する
  • クライアント側の操作が煩雑なためあまり普及していない
WSSE認証
  • HTTP1.1では標準外。AtomPubなどのWebAPIの認証に使われる
  • パスワードそのものをNW上に流す必要がなく、Digest認証ほど手間がかからない
  • ただしサーバ側では生のパスワードを保存しておく必要がある
補足：OAuth
  • Webサービス間でデータをやり取りできるようにするための仕様(認可の移譲)

キャッシュ

  • サーバから取得したリソースをクライアントのローカルに蓄積し再利用
ヘッダに持つ情報
  • キャッシュ可能かどうか(Pragma)
  • 有効期限(Expires)
  • 詳細なキャッシュ方法(Cache-Control)：上記2点のヘッダの機能を代用可能
ETag
  • キャッシュされたリソースにはエンティティタグ(ETagヘッダ)の情報を持つ
  • リソースの更新状態を比較するために使用する(更新すると値が変わる)

持続的接続

  • HTTP1.0ではクライアントが確立したTCPコネクションをレスポンス返却のたびに切断していた
  • HTTP1.1では接続し続ける仕様となった
  • レスポンスを待たずに同じサーバにリクエストを送信できる(パイプライン化)ため、より効率的にメッセージを処理できる
  • 切断する場合は、リクエストのConnectionヘッダにcloseという値を指定する

【読書記録】Webを支える技術　第3部②

第7章　HTTPメソッド

8種類のメソッド

  1. GET
  2. POST
  3. PUT
  4. DELETE
  5. HEAD
  6. OPTIONS
  7. TRACE：ほとんど使われていない
  8. CONNECT：ほとんど使われていない

代表的なメソッド

  1. GET（読み込み）
  2. POST（作成）
  3. PUT（作成・更新）　※POSTで代用可能
  4. DELETE（削除）　※POSTで代用可能

POSTとPUTの使い分け（作成処理）

  • 上記の通り、POSTでもPUTでも作成処理が行える
POST
  • リソースのURIはサーバ側が決める
  • 例：Twitter
PUT
  • リソースのURIを指定できる
  • 例：Wikipedia
  • URIの文字数制限など考慮が必要なため、特別な理由がない限りPOSTを使用することが望ましい

PUT/DELETEのPOSTによる代用

なぜ代用を考えるのか
  • ブラウザによってはGETとPOSTしか対応していない場合がある
  • セキュリティ上の理由でプロキシサーバがGETとPOST以外のアクセスを制限していることもある
代用方法

条件付きリクエスト

  • メソッドを実行するかどうかの条件をつけ、実行有無をサーバが選択できるようにすることが可能
  • 例：ヘッダにリソースの更新日時を付加し、この日時以降更新されていたらGET処理を行う

べき等性(冪等性)と安全性

べき等性
  • ある操作を何回行っても結果が同じになること
  • PUTやDELETEはべき等。同じPUT(DELETE)を何回行っても同じ結果
安全性
  • 操作対象のリソースの状態を変化させないこと
  • GETとHEADは安全
POST
  • POSTは安全でもべき等でもない
  • リクエストの結果、リソースが変化する可能性もあれば前回と結果が変わる可能性もある

※PUTがべき等でなくなるパターンなど、例外も本書内で紹介されている

まとめ

下記の点でHTTPはすぐれたプロトコルといえる
  • HTTPは限られたメソッドで構成される＝RESTの統一インタフェース制約
  • GETの安全性
  • PUTとDELETEのべき等性
  • いざとなればなんでもできるPOST

第8章　ステータスコード

分類とよく使われるコード

  • 先頭の数字で場合分けすることでCL/SV間の約束事を減らし、結びつきをゆるやかにする効果(疎結合)
1xx：処理中
2xx：成功
  • 200：リクエスト成功
  • 201：リソース作成成功
3xx：リダイレクト
  • 301 リソースの恒久的な移動
  • 303 別URIの参照
4xx：クライアントエラー
  • 400 Bad Request リクエストの間違い
  • 401 Unauthorized アクセス権の不正
  • 404 Not Found リソースの不在
5xx：サーバーエラー

【読書記録】Webを支える技術　第3部①

第3部の構成

  • HTTPの基本：TCP/IPの基礎知識、HTTPのメッセージ構造、ステートレス性
  • HTTPメソッド：各メソッドの特徴、べき等性
  • ステータスコード：コードの分類と意味、エラー処理
  • HTTPヘッダ：ヘッダの歴史、構成内容、認証方式など

第6章　HTTPの基本

HTTPとは

  • Web上でクライアント/サーバ間でリソースをやり取りするためのプロトコル
  • RESTの特徴である統一インタフェース、ステートレスサーバ、キャッシュなどを実現し、Webの基盤となっている

TCP/IPとは

  • HTTPはTCP/IPをベースにしている
IP
  • OSI参照モデルにおけるインターネット層にあたり、ネットワークでデータを実際にやりとりする
  • データをやり取りする際は指定したIPアドレスを送り先として、パケット単位で送る
  • 自分のネットワークから送り出すところのみを保証し、送り先まで届くかどうかは保証しない
TCP
  • OSI参照モデルにおけるトランスポート層にあたり、データの送信を保証する
  • 接続先の相手にコネクションを張り、コネクションを使ってデータの抜け漏れをチェックする
  • HTTPでは80番ポートをデフォルトで使用する

HTTPのバージョン

  • 本書執筆時点で最も広く使用されているバージョンはHTTP1.1

※すでにHTTP2や3が出ている時代なので、詳細は割愛します(本記事は初版2010年発行、2022年に発行された第16刷をもとに執筆)

HTTPの仕組み①クライアントとサーバ

  • クライアント・・・Webブラウザ
  • サーバ・・・Webサーバ。情報を提供
  • クライアントがサーバに接続する際にリクエストを出してサーバからレスポンスを受け取る(リクエスト／レスポンス型)

HTTPの仕組み②リクエストとレスポンス

  • リクエスト後、クライアントはレスポンスが返るまで待機する(同期型)
  • URLをたたいてWebサイトにアクセスした際の処理の流れを下記に記載
クライアント側
  1. DNSを使ってURLからホスト名を名前解決し、取得したIPアドレスのTCP80番ポートに接続し、リクエストを送信する
  2. レスポンスメッセージを受信
  3. 解析し、さらにリクエスト発行が必要なら繰り返す(画像やスタイルシートへのリンクが含まれている場合など)
  4. 返ってきたHTMLをレンダリングしてウィンドウに表示する
サーバ側
  1. リクエストメッセージを受信したら解析
  2. 該当ページのHTMLをレンダリングするアプリケーションに処理を委譲し、結果のHTMLを取得
  3. ヘッダを付加してレスポンスメッセージを構築
  4. レスポンスメッセージをクライアントに返す

HTTPの仕組み③HTTPメッセージ

リクエストメッセージ
  • 1行目は「リクエストライン」
  1. メソッド(GETなど)
  2. リクエストURI(/test?debug=true～～～)
  3. バージョン(HTTP/1.1)

※複数のヘッダを持つことができる
※省略可能

  1. 「名前：値」という形式
  2. Hostヘッダ(必須)　(Host: example.jp:8080) ←ポート番号を指定
  • ボディが続くこともある(更新するリソースなど)　※省略可能
レスポンスメッセージ
  • 1行目は「ステータスライン」
  1. バージョン(HTTP/1.1)
  2. ステータスコード(200など)　←リクエスト成功時
  3. テキストフレーズ(OKなど)
  • 2行目以降は「ヘッダ」　※省略可能
  • ボディが続くこともある(HTMLなど)　※省略可能
  • ヘッダとボディは空行で区切られる

HTTPの仕組み④ステートレス性

  • HTTPはステートレスの仕組みを採用している
ステートフル
  • 簡潔
  • サーバがそれまでのクライアントのリクエストを覚えている(われわれ人間の会話もステートフル)
ステートレス
  • 冗長
  • クライアントは毎回それまでのリクエストも含め、繰り返しリクエストする

Salesforceのフローの使用場所を確認する方法

Salesforceのカスタム項目の画面には「使用場所」のボタンがあり、どの画面や処理で項目を使用しているかを確認することができますが、
項目以外でも「このリソース、どこで使ってたっけ？」と悩むことがあります。

今回、フローを題材にメタデータで使用場所を検索する方法をまとめます。
VS Codeを使用します。

こちらのオンラインセミナーで作成した、ケースを作成するフローを題材にします。
コード初心者でも大丈夫。Einstein GPTでApex開発に挑戦！ #Salesforce - Qiita

大まかな手順

  1. VSCodeでメタデータを取得する
  2. フローのAPI参照名でメタデータを検索する

VS Codeでメタデータを取得する

※拡張機能「Salesforce Package.xml Generator Extension for VS Code」をインストールしておくと便利です。
また、取得したメタデータに漏れがあると、そもそも検索できないので注意です。

package.xmlに検索対象としたいリソースを記述する

今回の私の場合、フローそのものとアプリケーションページを追加しました。

  • FlexiPage
  • Flow


メタデータを取得する

package.xml上で右クリックし、SFDX: Retrieve Source in Manifest from Orgを実行します。

フローのAPI参照名でメタデータを検索する

ホーム画面に配置していることがわかりました。

Salesforce画面上で確認できるようになれば嬉しいですが、メタデータを使いこなせるとリリース時などにも便利なので、今後もこの方法を活用していきたいと思います。

補足「Flow」と「FlowDefinition」について

フローのメタデータとして「Flow」「FlowDefinition」の2種類がありますが、下記の違いがあります。

  • Flow：フローの定義内容の詳細

  • FlowDefinition：現在有効なバージョン

【読書記録】Webを支える技術　第2部

第2部　URI

※筆者が他の章を先に読み進めたい都合上、現時点では簡単なまとめのみとさせていただきます

URIのポイント

  • リソースの名前である
  • 寿命が長い
  • ブラウザのアドレス欄に表示する

URLとの違い(URIとURLとURN)

  • URLとURNを総称したものが「URI」
  • URNは次のような表記。リソースに恒久的なIDを振り、それを用いてアクセスする

　　urn:isbn:12345678901234567890

  • URLを用いる場合、サーバ障害、ドメイン変更などで使用できなくなる可能性がある
  • 最近はURLを永続的に使えるようにすべきという考え方が浸透し、ほとんどURLが使用されている

【読書記録】Webを支える技術　第1部②

第3章　REST

アーキテクチャスタイルとしてのREST

RESTにとって重要な「リソース」の概念

  • リソースとはWeb上に存在する、名前を持ったありとあらゆる情報

　例：東京の天気予報、東京駅の写真、このブログ

  • リソースはURIで識別でき、それによりプログラムは情報にアクセスできる
  • URIの登場前は、ディレクトリ名やファイル名、ログイン情報を伝える必要があった
  • 1つのリソースに複数のURIをつけることもできる

RESTを構成する特徴

  • 下記6つの特徴を持つ
  • クライアント／サーバ(ここに下記5つの制約を付加したものがREST)

　：UI(クライアント)と処理(サーバ)を分離することで、マルチプラットフォーム(PCやスマホ、ゲーム機・・)が実現できるなどの利点

  • ステートレスサーバ

　：サーバ側でアプリケーションの状態を持たないことで、サーバの実装を簡略化できる
　　※例外としてHTTPをステートフルにする要素：Cookieを使ったセッション管理

  • キャッシュ

　：一度取得したリソースをクライアント側で使いまわすことで、サーバとの通信を減らし処理を効率化する

  • 統一インタフェース

　：インタフェースを固定。たとえばGETやPOSTなど8個のメソッドしか定義しないことで、実装の独立性が向上する

  • 階層化システム

　：ロードバランサやプロキシをCL/SV間に設置できるが、CL側はそのことを意識せずSVを利用できる（統一インタフェースを採用することで階層化が可能になる）

  • コードオンデマンド

　：プログラムをクライアントにダウンロードして実行する　例）JavaScript