JSON限定 - いまさらながら Javaフレームワークを自作した（10年ぶり3回目） #03

Last updated at 2026-04-11Posted at 2026-01-29

はじめに

今回は SIcore の設計の中心にある 「通信はJSON限定」 についてまとめます。

この記事で書くこと

「通信はJSON限定」とは
ブラウザ〜サーバーの処理フロー
役割分担とページ遷移手順（JSP的な手順との差分）
メリット／デメリット

「通信はJSON限定」とは

SIcore では、ブラウザとサーバー間のやり取りを JSONに限定する設計にしています。

Webサービスへのリクエストは JSON形式（または URLパラメータ）
Webサービスからのレスポンスは JSON形式のみ
HTML は ブラウザが静的ファイルとして取得するだけ（サーバー側で HTML を動的生成しない）

言い換えれば「サーバーは値の入った HTML を返さない」という割り切りです。

ブラウザ⇔サーバーの処理フロー

[ブラウザ] Webページを表示
     │
     │ 1. 入力 → ボタン押下
     ▼
[JavaScript]
     │ 2. HTML上の入力値から JSON を生成して Webサービス呼び出し
     ▼
[Webサービス（Java）]
     │ 3. JSON を受け取り、処理し、JSON に詰めて返す
     ▼
[JavaScript]
     │ 4. JSON（Webサービスの戻り値）を HTMLにセット
     ▼
[ブラウザ] 表示が更新される

Webページ（ブラウザ）側：HTML と JavaScript の役割分担

HTML: 値を入力・表示するだけ
JavaScript: 入力値→リクエストJSON作成、Webサービス呼び出し、レスポンスJSON→表示

// 入力値→リクエストJSON作成
const req = PageUtil.getValues();
// Webサービス呼び出し
const res = await HttpUtil.callJsonService('/services/exmodule/ExampleListSearch', req);
// レスポンスJSON→表示
PageUtil.setValues(res);

Webサービス（サーバー）側：Mapクラスで処理する

少し話がそれますが、
SIcore ではサーバー側で JSONデータを Map として扱うことができます。
また Map はリクエストであり、そのままレスポンスにもなります。

  /** Webサービス処理 **/
  public void doExecute(Map io) {
    // リクエストから HTML入力値を取得
    String userId = (String) io.get("user_id");
    //  :
    // 何か処理して
    //  :
    // レスポンスとして返す
    io.put("user_nm", "...");
  }

この「リクエストとレスポンスが一体」という割り切りでコード量が減り、Webページの値をそのまま扱う感覚（JavaScript と似た感覚）になります。

ページ遷移は「HTML取得」＋「初期値取得」

ここが従来のJSP的な考え方と一番ズレやすいところです。

JSP的な手順（サーバーで次ページの HTML を作る）

フォーム送信（submit）
Webサービス処理
- 正常時は遷移先HTML（JSP）を初期値込みでサーバーが作って返す

JSON限定設計（HTML は静的、サーバーは HTML を作らない）

JSON送信
Webサービス処理（JSONで結果を返す）
正常時はブラウザが遷移先HTML（静的ファイル）を取得
遷移先の初期処理 JavaScript で、初期値を Webサービスから取得して表示

WebAPI（Webサーバー間通信）も同じ作りに

「サーバー⇔サーバー」処理のインターフェースも JSON限定に揃えると、「ブラウザ⇔サーバー」処理と同じ書き方で実装できます。
また、UI と API の境界が明確になるため、「ブラウザ⇔サーバー」処理のコードを「サーバー⇔サーバー」処理へ流用しやすくなります。

Postman等でテストしやすい

Postman でリクエストJSON を投げる
返ってくるレスポンスJSON を確認する

という方法で、Webページが完成していない段階でもサーバー側の動作をテストできます。

メリット

多くは Ajax のメリットともいえますが。

Webページ全体の再描画が不要になり、必要な箇所だけ更新できる。これによりブラウザ側での状態保持（検索条件など）が容易になる
WebページとWebサーバーの責務分離が明確（HTMLは静的、業務処理はJava）
URLマッピングと組み合わせると「迷う場所（設定・魔法）」が減る（初心者と AI 向け）
Webサーバー処理の途中でユーザー確認が必要な処理も実装しやすい
正常終了後にブラウザ側ストレージ（sessionStorage）を使うタイミングがある（JSPには無い）
単純に通信量が減る

デメリット

データ送受信時に常に JavaScript 処理が必要となるため、ブラウザ側でエラーが発生するリスクが高くなる（Ajax 共通のリスク）
「正常時にページ遷移して表示」の作りは、JSPと同じ感覚で書くと戸惑う
- 遷移先HTML は静的取得
- 初期表示値は JSON取得
- という2段階になる
ファイルアップロードは JSON だけでは完結しないため、別途方式（マルチパートフォーム送信等）が必要

おわりに

JSON限定設計は「何でもできる万能設計」ではなく、
Web業務アプリを、一定の型で速く・迷わず作るための割り切りだと思っています。

次回は、この記事でも触れた「静的HTML（モックアップ）」の扱い方を、もう少し深掘りして書く予定です。

SIcoreフレームワークリンク

実装コードと資料はすべてこちらで公開しています。

HP: https://onepg.com/ja/
GitHub: https://github.com/sugaiketadao/sicore-ja
サンプル画面の確認方法: https://github.com/sugaiketadao/sicore-ja#%EF%B8%8F-%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E7%94%BB%E9%9D%A2%E3%81%AE%E7%A2%BA%E8%AA%8D%E6%96%B9%E6%B3%95---vs-code
AI開発の始め方: https://github.com/sugaiketadao/sicore-ja#-ai%E9%96%8B%E7%99%BA%E3%81%AE%E5%A7%8B%E3%82%81%E6%96%B9

読んでいただきありがとうございました！
❤いいね！をしていただけると励みになります。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up