RESTの次は、窓口を通るデータの中身へ
K-03では、リソースをURLで表しメソッドで操作するRESTの考え方を学びました。設計の形が決まったので、今度はその窓口を実際に通っていくデータの中身に目を向けます。私たちがオブジェクトとして扱っているデータは、そのままの姿では通信できません。この講義では、送る直前と受け取った直後に起きている変換の仕組みを押さえます。
このスライドのポイント
- K-03: リソースをURLで表し、メソッドで操作するRESTの考え方を学んだ
- 設計の「形」が決まったので、今度は窓口を通っていくデータの「中身」を見る
- この講義の役割: 送る直前・受け取った直後に起きる変換の仕組みを押さえる
シリアライズ・デシリアライズ・JSONの定義
シリアライズとは、メモリ上のデータ、つまりE-09で見たオブジェクトを、通信や保存ができる文字列へ変換することです。その逆に、文字列をオブジェクトへ戻すことをデシリアライズと呼びます。この文字列表現の標準形式が、D-03から実際に使ってきたJSONです。JSONはここで初めて正式に定義しますが、これまで通信の中身として何度も目にしてきたものです。通信の両端では、必ずこのシリアライズとデシリアライズが起きています。
このスライドのポイント
- シリアライズ: メモリ上のデータ（E-09のオブジェクト）を、通信・保存できる文字列へ変換すること
- デシリアライズ: その逆。文字列をオブジェクトへ戻すこと
- JSON: その文字列表現の標準形式（D-03から使ってきたもの、の正式定義）
- 通信の両端では必ずこの変換が起きている
なぜ必要か——型ずれの原因が読めなくなる
この仕組みを知らないと、「送ったはずのデータが文字列になっている」「数値のはずが揃わない」といった型のずれの原因が読めません。これはE-02で触れた型の食い違いが、通信をまたいで起きている状態です。さらに、関数や日付のオブジェクトのように、そのままではJSONにできないものを送ろうとして起きる事故もあります。変換の存在を意識できて初めて、こうした不具合の切り分けができるようになります。
このスライドのポイント
- 知らないと:「送ったはずのデータが文字列になっている／数値のはずが揃わない」型ずれの原因が読めない
- これはE-02の型の食い違いが、通信をまたいで起きている状態
- 関数・日付のオブジェクトなど、そのままJSONにできないもので起きる事故もある
構造——変換は境界の2箇所で起きる
データの流れを往復で見てみましょう。フロント側のオブジェクトは、送信の直前にシリアライズされ、JSON文字列になります。その文字列がD-03の通信に乗ってサーバーへ届きます。サーバー側では、受け取った直後にデシリアライズして、再びオブジェクトへ戻します。変換が起きるのは送信の境界と受信の境界、この2箇所です。
このスライドのポイント
- フロントのオブジェクト →（シリアライズ）→ JSON文字列 →（D-03の通信）→ サーバーへ
- サーバーは受け取った直後にデシリアライズしてオブジェクトへ戻す
- 変換が起きるのは「送信の境界」と「受信の境界」の2箇所
具体例——日付の罠
具体的な落とし穴として、日付を見てみます。プログラム上の日付は専用のオブジェクトですが、JSONにできる型は限られているため、シリアライズされると文字列になります。受け取った側では、それは日付ではなく単なる文字列です。日付として計算や比較に使うには、もう一度日付へ変換し直す必要があります。「受け取った日付がおかしい」「時刻がずれる」といった不具合の定番の原因が、この戻し忘れです。
このスライドのポイント
- プログラム上の日付は専用のオブジェクト。だがJSONにできる型は限られる
- シリアライズすると日付は文字列になる
- 受け取った側で日付として使うには、もう一度日付へ変換し直す必要がある
- 「受け取った日付がおかしい／時刻がずれる」の定番原因＝戻し忘れ
技術サンプルカード
サンプルを見てみましょう。オブジェクトをJSON.stringifyで文字列に変え、JSON.parseでオブジェクトへ戻す、往復の最小例です。注目してほしいのは、金額の数値はそのまま戻る一方で、日付は文字列のまま戻ってくる点です。通信の前後では必ずこの変換が入り、型は変換によって変わりうる、という2つを押さえてください。AIに連携を作らせたら、型が変わるデータがどこで元へ戻されているかを質問して確かめましょう。
混同しやすい概念——JSONとオブジェクト
混同しやすいのが、JSONとオブジェクトです。JSONはあくまで文字列としての形式で、オブジェクトはE-09で見たメモリ上の構造です。画面上では波括弧の見た目が似ていますが、片方は文字の並び、もう片方はプログラムが直接操作できるデータで、まったくの別物です。E-02で見た、数値の1000と文字列の1000が別物だった問題の、遠い親戚だと考えてください。
バイブコーディングでの確認点
確認の習慣です。日付や、桁の大きい金額が絡むAPIでは、「型の変換はどこで行っていますか」を必ず確認してください。予防策としては、K-02のAPI契約の入力欄と出力欄に、それぞれの項目の型を明記させておくのが有効です。契約の段階で型を決めておけば、変換の戻し忘れそのものが起きにくくなります。AIに任せきりにせず、型の扱いを一度自分の言葉で確認するようにしましょう。
このスライドのポイント
- 日付・桁の大きい金額が絡むAPIでは「型の変換はどこで行っていますか」を確認
- 予防策: K-02のAPI契約の入力欄・出力欄に、各項目の型を明記させておく
- 契約の段階で型を決めれば、変換の戻し忘れそのものが起きにくくなる
- AIへの質問例:「この項目は送受信でどの型になりますか。日付はどこで戻していますか」
一問一答とまとめ
最後に一問一答です。オブジェクトを通信できる文字列に変換することを、何と呼ぶでしょうか。（間）答えは、シリアライズです。逆に文字列をオブジェクトへ戻すのがデシリアライズでした。30秒まとめとして、通信の両端では必ず変換が起き、その際に型は変わりうる、この2点を覚えてください。次回K-05では、そのやり取りに「誰が呼んでいるか」の情報を載せる、認証付きAPIへ進みます。関連資料は「API連携ワード100」と「エラー解決プロンプト50」です。
このスライドのポイント
- 一問一答: オブジェクトを通信可能な文字列にすることを何と呼ぶ？ → シリアライズ
- 30秒まとめ: 通信の両端では必ず変換が起きる／その際に型は変わりうる
- 次回K-05: やり取りに「誰が呼んでいるか」を載せる認証付きAPIへ
- 関連資料: 「API連携ワード100」「エラー解決プロンプト50」
