OfficeFloor has always been about Inversion of Coupling Control: not just injecting objects, but injecting the functions and threading too. For a long time, the way you expressed that wiring was graphical, a single configuration file with boxes and lines showing how your functions connected together.
It looked great in a demo. It did not survive contact with a team.
The problem with one big graphical file
A single graphical configuration file is fine when one person is building the application. The moment a second or third developer starts working on the same project, that file becomes a bottleneck. Two developers add two different endpoints, both touch the same file, and now someone has to merge a diagram. Graphical formats don't merge the way text does. There's no good way for a merge tool to reconcile two sets of moved boxes and re-routed lines. You end up resolving it by hand, in the underlying XML, squinting at coordinates and generated identifiers to figure out what actually changed.
That's a hard sell to any team used to git merge just working.
One YAML file per endpoint
OfficeFloor v4 replaces the single graphical file with one YAML file per REST endpoint. The file name itself encodes the HTTP method and the URL path, so the configuration and the routing are the same thing:
src/main/resources/officefloor/rest/
greeting.GET.yml → GET /greeting
greeting.POST.yml → POST /greeting
greeting/{name}.GET.yml → GET /greeting/{name}
Inside the file, named steps wire functions together, each naming the Java class (and, where needed, the method) that implements it:
validate:
class: ValidateGreetingLogic
outputs:
valid: build
build:
class: PostGreetingLogic
next: audit
audit:
class: AuditGreetingLogic
That's the entire specification for a three step pipeline of validate, build, and audit, with conditional branching and sequential composition both declared right there in the file. None of the three classes knows about the other two. The YAML is the only place that knows the order and the wiring.
Why this works so much better for teams
Each endpoint now lives in its own small text file. Two developers adding two different endpoints touch two different files, so there's nothing to merge. Even when two people do need to touch the same endpoint, it's a small YAML file, not a generated diagram, so a normal text merge actually works. When it doesn't, the conflict is a few readable lines rather than a tangle of graphical coordinates.
It also turns out this same property of small, explicit, readable files is exactly what helps AI coding tools. An endpoint's steps, their order, and their branches are all explicit in one file rather than implied by a call stack. That gives AI tooling (and, frankly, any developer new to the codebase) a direct index into the small, focused functions behind each step, rather than something it has to reconstruct by reading framework conventions.
Built on Spring Boot, not instead of it
This change comes with v4 moving OfficeFloor onto Spring Boot as its base. Add the starter to your existing pom.xml, and you can start declaring endpoints as YAML files alongside your existing @RestController classes, with no migration required. Spring's dependency injection, security, persistence, and actuator configuration are untouched. Spring beans are injected into your step methods exactly as they would be into a controller. OfficeFloor isn't replacing Spring; it's taking over just the wiring of REST endpoints, where the graphical file used to live.
<!-- Add to existing pom.xml --> <dependency> <groupId>net.officefloor.springboot</groupId> <artifactId>officefloor-rest-spring-boot-starter</artifactId> <version>4.0.2</version> </dependency>
Where to go next
The tutorials walk through this in detail, starting with Spring REST for the basics of YAML endpoint files, and the Function Injection tutorial for multi step pipelines with conditional branching. From there the tutorials cover validation, exception handling, Spring Security, OpenAPI generation, thread injection, and more, all configured the same way, one YAML file per endpoint.
If you've used OfficeFloor's graphical configuration before, this should feel familiar in spirit and much easier in practice. The functions are still composed, not coded together. They're just composed in a format your team's tools already know how to handle.
