Skip to main content

The Concept

Reusable response objects are implemented as subclasses of AbstractObjectProperty. They define a fixed set of properties that can be included in multiple ApivalkResponseDocumentation definitions.

Built-in Examples

ValidationErrorObject

This object is used to represent a single validation error or a generic error message. Structure:
  • parameter (string): The name of the field that caused the error.
  • message (string): The human-readable error message.
  • errorKey (string): The machine-readable error code.
Usage in Controller:

Creating Your Own

You can create custom reusable objects by following these steps:
  1. Create a Property Collection: Extend AbstractPropertyCollection and add your properties.
  2. Create the Object: Extend AbstractObjectProperty and return your collection in getPropertyCollection().

Example: UserObject

This example shows an object schema used for documentation and, optionally, as a runtime data container.
  • The constructor must call parent::__construct($name, $description).
  • Do not hydrate runtime values in the constructor. The documentation needs to be built independently of real values.
  • Populate the object only when you actually need an instantiated object at runtime, for example in populate(), a builder, or from a DTO.
Usage:
Alternative population strategies You can populate the object however you prefer, for example:
  • from a database record
  • via setters/getters
  • with a fluent builder
  • by mapping a DTO
The key rule is: constructor is for schema identity (name, description), not for data hydration.

Benefits

  • Consistency: All endpoints returning a “User” will have the exact same structure.
  • Maintenance: If you add a field to the UserObject, it is automatically updated in the OpenAPI documentation for all endpoints that use it.
  • DRY: You don’t have to redefine the same properties repeatedly.