REST API refactoring.
summary
API design must be treated as a live product because changes are effectively irreversible and affect many users; common problems include parameters hell (tens of optional query params), ignored HTTP verbs, RPC-over-HTTP and oversized payloads. Practical refactors: identify resources, segregate subdomains, split or join endpoints, use defaults or move rare options to headers, add pagination/field filtering, keep URL hierarchy to two or three levels, and add an API gateway or back-end for front-end layer to transform responses (Apigee or conc cited). Real case: merging two ticket systems requires full redesign, not simple translation.
AI-written summary · about
chapters (25)
- 0:00Introduction
- 1:13Welcome
- 2:47What is API
- 3:21Importance of API
- 5:13API design principles
- 5:47Common issues
- 6:05Parameters
- 8:01HTTP verbs
- 8:44REST API
- 9:53API payload
- 11:23philosophic question
- 11:54API design
- 13:41API refactoring techniques
- 14:09Clear resource definition
- 16:37Big domain
- 18:34Single responsibility
- 19:47Hierarchy
- 21:15API Gateway
- 25:14API Gateway vs API Facade
- 26:48API Gateway Pattern
- 27:54Big Integration
- 31:29My point of view
- 32:45Real life cases
- 35:28Business case
- 38:09Conclusions
