Hello. I am building a REST API that will potentiality service various applications. My inclination is to allow the client to maintain its own (user defined but unique) names for resources in the API DB. The idea is that a client wants to maintain its own (unique) names for objects, not ones generated by the DB.
I see two ways to do this. Require the client to make the mapping between internal naming conventions that humans would understand to the DB keys, or have a mapping on the API that resolved the client names to the proper resources. Then each “POST” would include the client’s name, and a “GET” could contain a json object that includes the client’s name for the object. Seems like the second approach might make building and maintaining client apps easier.
Since I am new to REST APIs, I was wondering if there is an accepted approach to implementing this?
To clarify a bit, the API maintains essentially a set of tree structures, and each new client application would talk to a new root node in the tree. Names of the objects in the tree could be some concatenation of the path down the tree structure, which would essentially bake in a name spacing convention that would ensure uniqueness of client names, even if two apps had similar names for objects in the tree.
It’s somewhat hard to tell what you want to make, but it sounds like you want to make an API service that can be used to create API services dynamically. This includes being able for clients to create endpoints + “database stuff” via an API, that can then be used.
The hard part of this sort of requirement is it can easily fall prey to “inner platform effect”. Since you’r essentially building an API to build API’s.
I’m not sure why’d you aim for such a dynamic setup, but most of the work you will put into supporting this sort of dynamic API building API, could be put to building specific APIs for your various applications.
If the goal is to build this dynamic API building API, then you could use pre-existing systems that already have done this. Firebase is a platform that comes to mind.
Otherwise your looking at a lot of work that goes beyond just what naming conventions you use for REST APIs. Something as simple as how do you secure each application calls between each other? IE if my app as users I want to call /users, but then my friend also has an app with users and also wants to call /users… you’d need to handle that, and determine how security works for each of those routes.
Furthermore, any user using my app can’t have access to my friend’s apps user’sand can only access their own user from the /user endpoint. This means your dynamic API needs to support my dynamic API that depends on who is “logged in” to my platform through your platform!
If your confused, then you can kinda see why building a dynamic API that builds API’s would be a complex project across the board.
