API Serialisation Profiles

The gap between an architectural model and an API contract is wider than it appears. A model entity might define a property called created_date with a datetime type, but the public REST API needs it as createdDate in ISO 8601 format, the GraphQL schema needs it as createdDate with a custom DateTime scalar, and the internal gRPC service expects created_date as a google.protobuf.Timestamp. Enum values in the model might be stored as integers, but the API should expose them as human-readable strings. Different consumers, different protocols, and different conventions all need different representations of the same underlying data.

API serialisation profiles bridge this gap by defining how model entities are transformed for each API output, without modifying the model itself. NeoArc Studio supports six API types, and each can have its own serialisation profile.

Profile Configuration

Each serialisation profile defines a set of conventions that control how model properties are transformed when generating API schemas.

One Property, Six Serialisations

The real power of serialisation profiles is visible when a single model property is projected across multiple API types. Each API target applies its profile rules independently.

How Profiles Work

Per-Field Overrides

While profiles define conventions at the global level, individual properties sometimes need exceptions. The per-field override system allows fine-grained control without abandoning the profile entirely.