3 ms·
My personal take: Don't put it all in the same box. Just have a api/v1/rest/ base path for modular well defined resources that can be used across your applicat
by sergioisidoro 3y ago
My personal take: Don't put it all in the same box.
Just have a api/v1/rest/ base path for modular well defined resources that can be used across your application, without breaking changes, or even shared to third parties.
Then have a api/v1/features for coupled endpoints that return non standard objects, and with a more flexible lifecycle.
Chances are you're better off having both instead of trying to cram all the use cases into one approach
- antonhag 3y agoMost times you won't need a well-formed (REST) API to start with, and many times you will never need it. Most small projects should start without one and create one when need arises.
- sergioisidoro 3y agoSure, you won't "need" them. But it's very likely that you'll have resources that behave very well for rest like operations - user comes to mind, for things like user profile page, user settings, user detail, etc A rest endpoint is likely handy to use across your application without having to replicate the same serialization over and over again. Also many frameworks remove all the boilerplate for those operations (eg. Django class views), so creating one is a really good starting point.
- indymike 3y agoI can't agree more: having a separate API for functionality and a separate one for non-standard (i.e. UI) is a great way to do this.
- nicodjimenez 3y agoThat’s a nice approach.