I would like to develop some API to give access to a software I’m working on.
The software structure is the following:
I’ve got some clients and for each of them I use separated databases, each client has access to a private area as administrator but also each client can create some regular user profiles and they can also access their private area.
Each website has his subdomain for example:
site1.website.com site2.website.con
And I use the first part of the subdomain to load the right database for each subdomain.
What is the best way to create an api that can deal with each website? Many thanks
Well ideally you have one API that is independent of the subdomains. You would issue an API key or use something like OAuth to authorize access to a website’s domain resources (DB etc). Based on the key or token, that will tell you which site it is for and what they can (or cannot) do.
In other words, your token/key determines the user which determines what that user can access. Aka User Permissions.
Now if you are wanting to do something more complex like site1.website.com/api, then that would be something that might be handled by rewriting the URL and having it pass site1 to the API to let it know it can only deal with site1’s resources. But I would probably steer clear of this for the time being. I would setup an API on something like… api.website.com that will take a key/token and use that to determine what resources it needs to access.
Of course I am just spinning stuff off the top of my head but having the one API that takes all requests and uses it to determine the site resources to access based on the key/token/user would be easy to manage, update and possibly add on to as services grow.
It seems, you need routing functionality to parse URL and check what is the current subdomain.And of course you need htaccess to redirect your requests to single bootstrap-script.
Hi @Martyr2 thanks for tour answer. Sorry I’ve never developed an API and this is a learning courve for me. If I understood then I can create a general API like api.website.com then I can create a general database where I can store all the subdomains and for each f them an unique API key that helps to identify the sobdomain and therefore to which database the API should connect is it correct?
Correct. You can associate an API key or token with a user or with a domain, an application or a service. You decide how that key works, but it is essentially an identifier of who is using the service, but also a key that can point to which service (aka domain in your case) they are trying to access. You could even say that an API key belongs to vince and vince is the owner of site1.website.com, so access site1.website.com.
But of course that is not the only way. You can issue keys or token specifically for a given website domain and in the database just associate the key with the ID of the domain and you are on your way.
Microsoft has their Entity Framework. I do not suggest you use that but it is an example of an Entity–relationship model; also see ER Model - Basic Concepts - Tutorialspoint. I am not sure that helps but it might help to conceptualize your data in such a manner. It seems to me that an ER model for use by a server and a client across the internet could be designed nearly the same as if they were in the same system.
Hi @Martyr2 many thanks for your help, so now that I know how I can use the API key to connect to a specific database can I ask another question?
I’ve read online something about JWT Tokens and what I understand is:
An external service (for example a smartphone app) makes a request to my api.website.com using the API key, I then show the login page then the user insert his credentials and if they are correct I authenticate the user and issue a JWT token wich is sent back to the external service (I suppose they need to store the JWT token somewhere) and then they can use the JWT token to make other requests to my API (passing it in the header? ) then all I need to do is extract the information from the JWT token and if it is not expired then I can show the private information? Is it correct? Many thanks
Correct. But usually API keys are issued are issued in secret. Haven’t you ever gone to a service where you wanted to use their API, you login, then go to a section to create an API key for some application you are building? I believe services like Twitter and Spotify do this (for app level access). Once you have the API key, your application can use the API key on requests. If the API key ever gets out into the public, you go to the service again, cancel the key and issue a new one.
Usually you would use either API key or OAuth or JWT. You can read about the differences in a nice article here…
Hi, yes I can create the API key inside the admin private area. I don’t know though how the API key cam be used to store the user informations (for example the user email or their ID) at the moment I save them into a SESSION maybe with the API key I can still save the informations in the server session? I read that with a JWT token I can store the information in the token itself. Thant thanks for your link
The API key doesn’t store information. It is used to access the information. You would store the information in your typical database or other systems. Your key determines what information you can see. Verify the key is valid, then look up the user who the key belongs to. Once you find the user, then you can read the user info and put it in a session or simply look it up on every request. Sometimes people use a cache for this too. You should be looking at the key on each request at least to make sure it is valid.
Hi @Martyr2 so I can create an API key for each user, save it in the database where the API is related to the user and the domain, then use that key to authorise the user login without using their username and password? Then if the key is correct I can save the user ID and their email i to a SESSION on the server or as you said check user details at each request using the API key as user identifier.
In general yes… the API key can be thought of as a secret identifier. So you should only be supplying the API key on requests that are SSL encrypted and shouldn’t be shared with anyone. If someone was to get a hold of the key, they then could essentially do whatever the API key allows them to do.
Because of this potential for leakage is one of the drawbacks of API keys and which you may want something like OAuth. But as long as you keep the API key secret and transmit it across SSL requests, you will be all good.
As I pointed out in the link to the articles a few posts back, it talks about the drawbacks of API Key one of which is it being leaked. I would try to keep API keys and users data relation to a minimum. You must decide how much power you assign to API Keys.
