REST beyond the obvious – API design for ever evolving systems
summary
Most REST-labeled APIs merely move CRUD over HTTP and break when clients replicate domain rules; versioning just spawns a new service and raises integration cost. Concrete proposal: model higher-level domain processes (example: coffee order state machine), expose link-driven clients instead of status-based semantics, and serve actionable links so adding a business rule is a server-side change. Tooling mentioned includes Spring HATEOAS and Spring Data REST plus docs/contracts via Spring REST Docs and Spring Cloud Contract.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 2:03API context and evolution
- 6:53Data access layer APIs
- 11:39Evolvability and coupling
- 21:54Defining API contracts
- 26:57Understanding conasence
- 30:59The problem with versioning
- 41:16Hypermedia solutions
- 47:06Spring tools and summary
related talks
01h 39mLet’s have some Effective REST
42mLet’s Have Some Effective REST!
01h 34mDesigning a REST-ful API using Spring 3
53mEffective Design of RESTful APIs
04mReal-World Enterprise REST API Design
46mLet’s have some effective REST!
42mREST API design good practices
56mDDD & REST - Domain Driven APIs for the Web