4 ms·
One of the biggest benefits I see to API-first is that it encourages you to document everything well, and that process usually leads to better organization and
by joshfraser 13y ago
One of the biggest benefits I see to API-first is that it encourages you to document everything well, and that process usually leads to better organization and greater consistency.
As far as fat vs. thin, I worry that this article could be a bit misleading. It's great if you have an API that responds in 20ms as very few people can achieve that. But it doesn't matter much in a world where mobile network latency can easily be 200-500ms. If you're worried about app performance, I'd focus first and foremost on the number of requests you are making and making sure none of them are blocking. The network is the slow part. I know a lot of companies with blazing fast API's and sluggish apps, because they're optimizing the wrong thing.
- PLejeck 13y agoWhen developing an API, I like to practice "documentation-oriented design." The first thing I do is write documentation of the API, and then I write APIs to fit that documentation (iterating both in parallel once I start writing the API). I figure that the documentation is the first thing a developer faces when using an API, so it should also be the first thing I write.
- dreamfactory 13y agoA related approach is client-driven development (just made it up). Write client code (or controller) in the most thin, elegant, and obvious brain-dead simple way, then build an API (or model) to service it.
- PLejeck 13y agoIt's okay, I totally just made up "documentation-driven development" too. And yeah, that's the best way I find. Always build a consumer and then build the supplier, you'll usually end up with a great experience.