3 ms·
A problem with nested URLs like /organizations/:organizationId/blogs/:blogId/sections/:sectionId is that when you are manipulating a section from the frontend,
by jraph 4y ago
A problem with nested URLs like /organizations/:organizationId/blogs/:blogId/sections/:sectionId is that when you are manipulating a section from the frontend, you don't only need to keep and pass around their sectionId, but also their organisationId and blogId everywhere. Often you'll already have those, but sometimes not and it'll be annoying, you'll have to make more complex code with functions taking more parameters than necessary. From the backend, you'll need to check that all those ids are consistent and match.
It's also possible you will need at some point to re-use sub objects in a new context, so you'll have different kinds of paths to query those sub objects.
I'd go with Python's guideline "Flat is better than nested" here, and in doubt, follow it.
I think nested is only appropriate if you want to ensure the requester knows the oragnisationId, the blogId and the threadId of a particular comment to access it. Otherwise, it will lead to more complexity everywhere.
- tasuki 4y ago> From the backend, you'll need to check that all those ids are consistent and match. Or you don't check and just discard all the superfluous parameters, I've seen that too unfortunately. All your points are valid of course :)
- jraph 4y agoYup. Actually though about that possibility while writing this. Quite like I would not use a function argument if I don't need it. So I would avoid putting these parameters in the function signature in the first place. It just leads to confusion at best, and there's a good reason why many compilers emit warnings for this. I believe a function should only take the minimum it needs, and I believe APIs should not be different in this matter. Redundancy is good when you actually need it, and not quite when you don't.