4 ms·
Disclaimer: This is not based on real world knowledge. (To be honest I have practically no "real world knowledge".) That being said, I just finished a school p
by t0astbread 7y ago
Disclaimer: This is not based on real world knowledge. (To be honest I have practically no "real world knowledge".)
That being said, I just finished a school project where we (our class) were divided into small teams and we had to implement small RESTful web apps. My team chose to kick it off by grabbing two people from the front- and backend team and writing an API specification by hand. It was a breeze and we were done in a few hours. After that front- and backend (almost) never had to interact with each other again until the end of the project where we had to stick the two things together.
This probably isn't applicable to real-world cases where the requirements are ever-changing and everyone's a full-stack dev (or you don't have a team at all) but I found this sort of separation quite useful for this project. (It kept team sizes managable, different kinds of devs were in seperate teams, we didn't have to wrestle with any tooling that would halt the whole project.)
I see no problem with generating client/server boilerplate from spec though (like Swagger does, I think).
- t0astbread 7y agoThis sort of philosophy could be useful when designing a public-facing API though. In that case you need a well-formed implementation-unaware API documentation and mapping it out upfront by hand could save you lots of trouble.