Production engineering
using System;
using System.Linq;
using System.Collections.Generic;
using System.Globalization;
using System.Text;
using System.Text.Json;
using System.Threading;
using System.Threading.Tasks;
foreach(string json in new[]{"{\"id\":1,\"name\":\"rune\"}","{\"id\":1,\"name\":\"rune\",\"state\":\"active\"}","{\"id\":1,\"displayName\":\"rune\"}"}) { using var doc=JsonDocument.Parse(json); var root=doc.RootElement; Console.WriteLine(root.TryGetProperty("name",out var name)&&name.ValueKind==JsonValueKind.String?"accepted":"rejected"); }
Reveal answer and reasoning
The first supplied JSON object has id one and name rune, so the companion prints accepted. The second retains those values and adds state active; the predicate still finds a string name and prints accepted. The third replaces name with displayName, so it prints rejected. The code does not validate every property or negotiate an API version. Its known fixtures isolate one consumer dependency: the required name property.
Another consumer can depend on different members or reject extras, which is why this single predicate cannot prove a universal backward-compatibility claim.
All three actual routes return200, but they intentionally expose different shapes. The two v1 examples retain name, while v2 uses displayName and an explicit state. Applying the stated name consumer distinguishes them independently of status. These requests verify route and representation behavior on real Kestrel; no external clients or production deprecation workflow are provisioned. The extra-field route is a controlled compatibility fixture, not an automatic promise that every v1 change is safe.
Request bodies, headers, status categories and errors can evolve incompatibly even when the successful JSON example remains readable.
What a strong answer covers
- The known name predicate prints accepted,accepted,rejected.
- All actual example routes return200, so status alone cannot prove representation compatibility.
- Compatibility is relative to supported consumer behavior, not guaranteed by an optional-looking field or v2 label.
Common pitfall
Using a versioned URL, successful status or server build as proof that existing clients remain compatible.
Follow-up questions
- Which strict consumer would reject an added field?
- How could an unchanged successful body still hide a breaking error or request contract?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.