CODEWITHSUNDEEP
sql-serverrestapiazureasp.net-web-api
Ghadawi
Ghadawi

Reputation: 1

What is the best practices for building REST API with different subscribers (companies)?

What is the best design approach in term of security, performance and maintenance for REST API that has many subscribers (companies)?

What is the best approach to use?:

  1. Build a general API and sub APIs for each subscriber (company), when request come we check the request and forward it to the sub API using (API Key) then retrieve data to general API then to client.

  2. Should we make single API and many databases for storing each subscribe(company) data (because each company has huge records that why we suggested to separated databases to improve performance)? when request come we verify it and change database Connection String based on client request.

  3. Should we make one API and one big database that handle all subscribes data?

Do you suggest any new approach to solve this problem? We used Web API and MS SQL Server and Azure Cloud.

Upvotes: 0

Views: 451

Answers (3)

Ankit
Ankit

Reputation: 83

What I understood from your question is, you want an rest API for multiple consumers(companies). Logically the employees from that company will consume your API, employees may be admin, HR etc. So what I suggested for such scenario you must go with single Rest API for providing the services to your consumers and for security you have to use OpenId on the top of OAuth 2. This resolves the authentication and authorization for you.

Upvotes: 0

matt_lethargic
matt_lethargic

Reputation: 2796

In the past I've had one API, the API is secured using OAuth/JWT in the token we have a company id. When a request comes in we read the company id from the JWT and perform a lookup in a master database, this database holds global information such a connection strings for each company. We then create a unit of work that has the company's conneciton string associated with it and any database lookups use that.

This mean that you can start with one master and one node database, when the node database starts getting overloaded you can bring up another one and either add new companies to that or move existing companies to take pressure off. Essentially you're just scaling out when the need arises.

We had no performance issues with this setup.

Upvotes: 1

Hiran
Hiran

Reputation: 1180

Depends on the transaction volume and nature of data, you can go for a single database or separate database for each company.

  • Option 2 would be the best , if you have complex data model
  • I don't see any advantage of going for option 1, because , anyway general API will call for each request.

You can use the ClientID verification while issuing access tokes.

Upvotes: 0

Related Questions