State Creation Operation

_{Published: 06 July 2025}

Known Uses

The pattern of creating new state via API operations (typically using POST requests to create resources or events) is a standard and widely adopted practice in both the Dutch government and energy sector APIs. Examples:

• The Notifications API in the context of Zaakgericht werken (case-oriented working) is a standardized service used by Dutch municipalities to automatically inform different software systems when something important happens in the case management process such as a new case being created, a status being updated, or a document being added. The Notifications API implements the state creation operation pattern by allowing systems to create (POST) new notification events on the notification router component. For example, when a new case is created or a status changes, the responsible component sends a POST request to the Notifications API with details about the event. A system sends a POST to /api/v1/notificaties with event details (like the type of action, affected case, and timestamp). This creates a new notification event in the notification router, making it available for other systems to receive and process.
• The DSP (Digital Collaboration Platform) is a messaging platform that facilitates the exchange of standardized messages between Grid Operators and Contractors, following a defined process. The Grid Operator initiates this process by sending an assignment message to the Contractor via the Assignment API. Upon receiving a POST /opdracht request through this interface, the Contractor’s system creates the assignment. Subsequently, an assignmentId is returned as minimal feedback to confirm successful creation.
• Behandeldienstconfiguratie beheren (Manage treatment service configuration) API: A RESTful HTTP API for managing treatment service configurations. It allows an administrative body to link an activity, for which it is the competent authority, to a treatment service. This API allows the creation of new configurations or associations and includes endpoints where clients can POST new configuration data – a State Creation Operation.
• Job Vacancy API: storing new job vacancies from the websites WerkenvoorNederland.nl and WerkenbijdeOverheid.nl. The API allows for the creation (opslaan) of new job vacancies. This is a classic example of a State Creation Operation: the client submits a new job posting, which is then stored server-side.

Discussion Input

It’s worth noting that the Command Message (EIP) aligns with the State Transition Operation pattern (see link), not the State Creation Operation. In Domain-Driven Design (DDD) and CQRS, a command expresses an intention to change system state – that change might create new entities or update existing ones. In that sense, “state creation” is simply a special case of “state change.”

By contrast, events are best viewed as variants of State Creation Operations: they append new facts or entities to the system without ever reading or modifying what’s already there. In an event-sourced system, these append-only records denote “what has happened,” whereas the actual state transitions are driven by commands.

An interesting observation is to view commands, events, and state from a time perspective:

• Commands capture user intent (a desired future state)
• Event record decisions that have already occurred (the past)
• State reflects the current snapshot of data at a given moment (the present)

See this LinkedIn post and this summary of Alex Lawrence’s talk “Messaging 101: The Basics of Message-Driven Systems”, which also has an additional EIP Mapping.

Recommended Reading

The book outlines various types of events, such as notifications, full reports, and delta reports. As Event-Driven Architecture (EDA) continues to gain momentum in our domains, it’s worth noting that – to the best of our knowledge – bulk or batch event processing (referred to as “bulk reports”) has not yet been adopted in our systems. For an overview of event types, see: Event Typology.