Skip to main content
WidgetExamples Logo

API Response Inspector

Path-based comparison for Flutter API payloads. Distinguishes missing from null, preserves large numeric lexemes, and inspects structural contract changes.

Open JSON Formatter
Response A — Baseline100 KiB limit
0%
Waiting for input…1 lines · 0 chars
Response B — Incoming100 KiB limit
0%
Waiting for input…1 lines · 0 chars
🔒 Local Sandbox (0 network requests)
User Guide: Comparing Stable vs Changed Responses in Flutter
Read Full Tutorial & Dart Code →
Limit 1: Observed Difference ≠ Server Contract Proof

An absent key in an observed response is an observed difference in that specific sample. It does not prove the field is optional or nullable in the backend contract. Always verify schema rules against your backend OpenAPI/Swagger specification.

Limit 2: Index-Based Array Alignment

JSON arrays are strictly ordered sequences. Unless arrays provide unique identity keys, array differences are inspected by index order. Reordering array items appears as index-level replacements rather than silent key matching.

Limit 3: 64-bit Lexical Numeric Precision

Standard JavaScript JSON.parse coerces numbers to 64-bit float doubles, losing precision for values > 253-1 (e.g. Snowflake IDs like 9007199254740993). API Inspector preserves numbers as exact lexical strings.

Limit 4: Local Sandbox Privacy Guarantee

0 network requests are made. All parsing, diffing, draft autosaving, and snapshot storage stay inside your local browser. By default, raw payload values are excluded from exported reports to prevent leaking tokens or PII.

Tool Specification: Tasks, Realistic Inputs, Outputs & Local Data Handling

Complete operational details, schema diffing categories, diagnostic error states, and strict client-side privacy guarantees for the API Response Inspector.

1. Task It Solves & Why It Matters

When migrating Flutter backends or upgrading REST endpoints, undocumented schema changes frequently trigger uncaught runtime TypeError exceptions (e.g. integer converted to string, unexpected null, or removed object key).

The API Response Inspector performs AST-level semantic diffing between Baseline (Response A) and Incoming (Response B) payloads. It accurately distinguishes missing keys from explicit null assignments, tracks array length modifications, detects mutated primitive types, and flags large 64-bit integer values that exceed JavaScript's IEEE-754 safe representation limits.

2. Realistic Example Inputs & Outputs

  • Baseline Input: v1 User payload with fields userId (int64), role: "senior", and string array tags.
  • Incoming Input: v2 User payload where role changes to "lead", new key joinedAt is added, and version is incremented.
  • Diff Output: Color-coded diff records (Added, Removed, Type Changed, Value Changed, Array Length).
  • Navigation: Clicking any diff chip jumps both paired editors directly to the line and column in the source text.

3. Input Validation, Actions & Error States

Both editor panes validate JSON syntax independently and provide immediate line/column error feedback with visual caret snippets.

  • Malformed JSON: Typing broken JSON displays a structured alert (Syntax Error on Line X) and disables comparison until corrected.
  • Reset Action: Clicking Reset to Samples reloads the default baseline and comparison datasets.
  • Export Action: Clicking Export Report produces a standalone Markdown (.md) or structured JSON audit report with privacy-by-default value omission.
  • Snapshots: Save comparison states to local IndexedDB storage for subsequent review or regression testing.

4. Limitations & Data Handling

Limitations: Supports valid RFC 8259 JSON up to 100 KiB per payload. Does not parse raw binary protocol buffers, GraphQL queries, or YAML directly.

Data Handling: All diffing math, line mapping, snapshot persistence, and report generation occurs client-side in browser memory. The tool itself never uploads your payloads. Like every page on this site, it loads Google AdSense, which uses cookies as described in our privacy policy. Sensitive proprietary API structures never leave your machine.

Flutter API Contract Engineering: Precision, Nullability & RFC 8259

Network payload mismatches are the leading source of uncaught production crashes in Flutter applications. Understanding transport-layer serialization quirks prevents subtle data corruption and runtime type exceptions.

1. The "Missing vs. Null" Distinction in Dart

In JavaScript, undefined and null are distinct primitives. In Dart and JSON, however, undefined does not exist — leading to dangerous API ambiguities.

In PATCH requests, sending {"avatar_url": null} explicitly clears the user profile picture. Conversely, omitting the key entirely (!json.containsKey('avatar_url')) means “leave unchanged”. Merging payloads blindly without checking key existence causes inadvertent state resets.

2. IEEE-754 Precision Limits in Dart Web vs. VM

On native Android and iOS runtimes (Dart AOT), integers are true 64-bit signed values capable of holding numbers up to 2^63 - 1.

However, when running Flutter on the Web (compiled to JavaScript), Dart integers compile to standard JavaScript Number primitives (IEEE-754 double precision floats). Any integer exceeding 2^53 - 1 (9,007,199,254,740,991) suffers silent truncation. 64-bit snowflake IDs (such as Twitter/Discord IDs or database BigInt keys) must always be transmitted as strings in JSON.

3. RFC 8259 Duplicate Keys & Parse Non-Determinism

RFC 8259 Section 4 specifies that JSON object names SHOULD be unique, but leaves the behavior of duplicate keys undefined. Different JSON parsers adopt conflicting resolutions:

  • Last-Key-Wins: Standard in browser JSON.parse() and Go's encoding/json.
  • First-Key-Wins: Present in certain custom C/C++ embedded parsers and legacy proxy servers.
  • Syntax Rejection: Strict parsers reject duplicate keys entirely. Our inspector flags duplicates immediately to prevent deserialization divergence across client platforms.

4. Safe Contract Migration Strategies

Unlike web applications where frontend and backend deploy simultaneously, mobile users may stay on older Flutter builds for months.

Never delete or rename existing JSON fields in place. Instead, apply the additive evolution pattern: add new fields alongside existing ones, deploy the updated mobile app, monitor deprecation telemetry, and only remove obsolete fields after legacy app version adoption drops below threshold.