For the first half of your response, you got what I meant by "structuring". I am more interested in the project layout than REST principles itself.
As for the versioning, what I meant was the api.example.com/v1 vs api.example.com/v2 how do you usually handle that? Is there a recommended project layout when preparing for this? Do you have models/v1/, models/v2 or something?
What you said makes so much sense. There is some kind of paradox in these good practices. So it's really a matter of taste and what my API is for then...
I have one last question. You mentioned that I could create a container folder for everything (this is what I want instead of leaving them to the project root), is there a naming standard for such folder? For example, the dist or build folders have a naming convention for the final build of the app. I know it's a trifle, but I want to adapt™ to the javascript nomenclature as early as possible.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
I've never had to worry about supporting multiple versions of a REST API at the same time, and I favor data access without models in JavaScript so that in particular is a bit of a moot point personally. I would try to avoid versioning models if at all possible simply because more code = more points of failure. There's no way around versioning routes because they have to do different things, but it should be possible to do those things with the same models even if you have to do a little fine-tuning here & there in the route code. If your schema is changing radically enough that that isn't practical, you probably have two different applications instead of two API versions. Unless you're tied into it for business reasons, such as "being Facebook", in which case all bets are off.
The conventional container folder name is "lib" in Node, although you'll occasionally see "src" instead.
Hi Dian! 🤗 Thank you very much for your answer!
For the first half of your response, you got what I meant by "structuring". I am more interested in the project layout than REST principles itself.
As for the versioning, what I meant was the
api.example.com/v1vsapi.example.com/v2how do you usually handle that? Is there a recommended project layout when preparing for this? Do you havemodels/v1/,models/v2or something?What you said makes so much sense. There is some kind of paradox in these good practices. So it's really a matter of taste and what my API is for then...
I have one last question. You mentioned that I could create a container folder for everything (this is what I want instead of leaving them to the project root), is there a naming standard for such folder? For example, the
distorbuildfolders have a naming convention for the final build of the app. I know it's a trifle, but I want to adapt™ to the javascript nomenclature as early as possible.Again, thank you for your response!
I've never had to worry about supporting multiple versions of a REST API at the same time, and I favor data access without models in JavaScript so that in particular is a bit of a moot point personally. I would try to avoid versioning models if at all possible simply because more code = more points of failure. There's no way around versioning routes because they have to do different things, but it should be possible to do those things with the same models even if you have to do a little fine-tuning here & there in the route code. If your schema is changing radically enough that that isn't practical, you probably have two different applications instead of two API versions. Unless you're tied into it for business reasons, such as "being Facebook", in which case all bets are off.
The conventional container folder name is "lib" in Node, although you'll occasionally see "src" instead.
All points taken. Thank you! 👏👏