A provider perspective shapes an API around internal structures, business logic, implementation details, or operational mechanisms instead of consumer goals. Avoiding it keeps capabilities and data reusable, versatile, and easier to consume. section 2.6.2 section 5.5.3
Product data that leaks implementation
A product price described as “add 10% on Fridays between 4 pm and 7 pm” exposes business logic consumers should not have to interpret. Likewise, grouping description and keywords under a summary object merely because a website uses that layout exposes presentation structure rather than useful product data. section 5.5.3
Apply these checks when identifying capabilities, modeling data, or securing an API:
- Balance all consumers’ needs without specializing the API for one consumer. section 2.6.2
- Model names, types, and organization around subject-matter needs, not implementation or user-interface structure. section 5.5.3
- Expose only necessary data and operations; leaking business logic can let consumers corrupt underlying systems. section 12.2.2
- Challenge apparent provider constraints before adapting the design, and consider alternatives such as REST when appropriate. section 14.1.3
