Add a single dependency to your existing Spring Boot
pom.xml and start declaring REST endpoints as YAML
files alongside your existing controllers.
Spring's dependency injection, security, persistence, and actuator configuration remain completely intact at every stage. OfficeFloor enriches Spring, it does not replace it.
<!-- Add to existing pom.xml (Spring Boot 4.x) --> <dependency> <groupId>net.officefloor.springboot</groupId> <artifactId>officefloor-rest-spring-boot-4-starter</artifactId> <version>4.0.2</version> </dependency> <!-- Spring Boot 3.x: officefloor-rest-spring-boot-3-starter -->
# File name = HTTP method + URL path src/main/resources/officefloor/rest/ greeting.GET.yml → GET /greeting greeting.POST.yml → POST /greeting greeting/{name}.GET.yml → GET /greeting/{name} # greeting.POST.yml: three composed functions validate: class: ValidateGreetingLogic outputs: valid: build build: class: PostGreetingLogic next: audit audit: class: AuditGreetingLogic
@RestControllerIn a Spring @RestController, the flow between
validation, business logic, and auditing is implicit. It lives in the
call stack and framework conventions. Ask an AI to add feature after
feature and that one method grows and tangles. The YAML keeps each
concern in its own small function. OfficeFloor wires them together in
the order the file declares.
Each function declares only its own Spring bean dependencies, injected by Spring exactly as in any other bean. No function knows about the others, and no annotation describes the wiring. The YAML file is the complete specification.
Conditional branching, sequential composition, and error flows are all declared in the same file. To add a feature you add a step: one small class and one line. So the endpoint stays tidy however many times an AI changes it.
In a Spring controller, the flow between an endpoint's steps is implicit. It is spread across the call stack and framework conventions. Which function runs next, which branch handles a validation failure, which step writes the response: none of it has a fixed home. So every time an AI adds a feature it decides again where the code goes. Bit by bit the controller erodes into a tangle.
OfficeFloor's YAML files are the specification. Every endpoint's steps, their order, and their conditional branches are explicit in one file. To add a feature an AI adds a step: one small class and one line. So your code stays tidy however many times it changes.
Just as Dependency Injection made dependencies first-class in the architecture by making them explicit, named, and wired in configuration rather than constructed inline, Function Injection makes function flow first-class. The wiring between functions is declared in configuration, not buried in the call stack.
Function Injection gives AI an explicit, contextual index into the codebase instead of implicit framework conventions.
And because the structure lives in the code itself, OfficeFloor needs no AI tooling. There is no Model Context Protocol (MCP) server or add-on to reconstruct how endpoints are wired. Documentation is enough. Where a framework's flow is implicit, such tooling is bolted on to recover what the code does not state. Function Injection removes the need.
