Home > OS >  REST api - client endpoint
REST api - client endpoint

Time:01-10

First of all, I am not really sure if I need to ask this here or on (for example) StackExchange ? Fell free to redirect me.

I am developing a website which has 2 parts :

  1. A connected part, for admins.
  2. An unconnected part, for customers.

And I am struggling with a best practice to have in my case.

The administrator pages call API endpoints which are protected with JWT. They can GET, POST, PUT, and DELETE data. The GET repository methods do not use EF's AsNoTracking() (for non-.NET devs, it allows to avoid tracking any changes on the database entities), as the admins could want to update the data.

The customers on the other hand, won't have the possibility to update data. It's only readonly, and will stay readonly in the future. As they are not connected and do not have a token, they can't call the same API endpoints than the admins.

I have multiple ideas to handle this but I do not know what is the best practice regarding REST.

  1. Create, in the same controller, other GET endpoints, with no token auth, that calls another repository method that uses AsNoTracking() to avoid any changes (even if it should not happen) on the entity, in addition to the (minor) performance improvement it causes.
  2. Create a separate controller, with a different route : api/Client/Controller/Action.
  3. (My least prefered option), remove token auth on admin's GET endpoints and conditionally add AsNoTracking() based on if the caller is a customer or an admin.
  4. Anything else that would be better ?

I feel like I do not have an option that is 'perfect' regarding code duplication or single responsibility principle.

Thanks

CodePudding user response:

After further investigations, the best option would be solution 2.

By creating a new controller, dedicated to customers, we can :

  1. Avoid mixing both JWT protected and non protected endpoints.
  2. Make a separation between administrators and customers, from both the endpoints route POV but also in the project architecture.
  3. Avoid having a big controller in which all endpoints would not be used based on if the caller is an administrator or a customer.
  • Related