1đź‘Ť
I’ll take a stab
The simplest reason is that surrogate keys like your 1 only mean something within the boundaries of your system. They are meaningless outside of the system.
Expanding on this, you could build your app such that there’s no limitations on the URLs that identify groups, only the conformance of the resources gathered from the response of those URLS. Someone could add a user in your system that is in a group in the FaceBook system, as long as the two systems could negotiate what a group is. There are standards for concepts like group, and it’s not impossible to do such a thing.
This is how most web apps work. EG: the citation links in a wikipedia article which can point to any other article (until the wiki trolls remove it for not being an appropriate citation resource…)
having your app work like this gets you closer to RESTful conformance. Whether or not you consider RESTful architecture a good idea is what you asked us not to discuss, so i won’t.
Another often cited benefit would be the ability for you to completely re-key your setup. You may dismiss this at first…but if you really use 1 for id’s, that’s probably an int or long, and you’ll soon run out of those. Also such an id means you have to sequence them appropriately. At some point you may wish you had used a guid as your id’s. Anyone holding on to your old ID scheme would be considered legacy. The URLs give you a little abstraction from this..old url’s remain a legacy thing, but it’s easier to identify a legacy url than it is to identify a legacy id (granted not much…it’s pretty easy to know if you’re getting a long or a guid, but a bit easier to see a url as /old/path/group/1 vs /new/path/group/). Generally using URLs gives you a little more forward compatibility and room to grow.
I also find providing URLs as identifiers makes it very easy for a client to retrieve information about that thing. the self link is so VERY convenient. Suppose i have some reference to a group:1….what good is that? How many UI’s are going to show a control that says “add group 1”. You’ll want to show more. If you pass around URLs as identifiers of selections then clients can always retrieve more information about what that selection actually is. In some apps you could pass around the whole object (which would include the id) to deal with this, but it’s nice to just save the URL for later retrieval (think bookmarks). Even more importantly it’s always nice to be able to refresh that object regularly in order to get the latest state of it. A self link can do that very nicely, and i’d argue it’s useful enough to always include…and if an always included self link identifies the resource…why do you need to also provide your surrogate key as a secondary identifier?
One side note. I try to avoid services that require a url as a parameter. I’d prefer to create the user, than have the service offer up possible group memberships as links, then have the client choose to request those state transitions from non-membership to membership. If you need to “create the user with groups” i’d go with intermediate states prior to actual submission/commitment of the new user to the service. I’ve found the less inputs the client has to provide, the easier the application is to use.