REST API Testing best strategy

I’m currently developing a personal project using Django REST + React and as it grows more complex, I want to add unit testing to ensure that changes don’t affect previous functionality. However, I’m not sure exactly what to test for. Should I simply test the responses from the API endpoints, should I try random input to check if it’s validated properly, should I try getting access or changing data that belong to a different user? What is the best strategy to ensure that a REST API is both stable and secure through testing?

Go to Source
Author: Antonis Karvelas

Is it a good practice to have an endpoint URL with parameter accepting different type of values?

In my current maintenance project, there is REST API resource URL like this:

/sites/<site id or site code>/buildings/<building id or building code>

In this endpoint URL, there are two parameters,

  • <site id or site code>
  • <building id or building code>

As the name indicates, these two parameters are ambiguous, say the value of the first parameter can be either site id or site code, the value of the second parameter can be either building id or building code. However, implicitly it means,

For instance, there is a building with 1 as building id and rake as building code, and it is located in the site with 5 as the site id and SF as the site code, then the following endpoint URL should retrieve the same result:

  • /sites/1/buildings/5
  • /sites/rake/building/5
  • /sites/1/buildings/sf
  • /sites/rake/building/sf

The implementation of such resource endpoint contains lots of if conditions due to the ambiguity**. However, from the end-user’s aspect, this seems to be handy

My quesiton is whether such endpoint design is a good practice or a typical bad practice?

Go to Source
Author: Rui

Is this an anti-pattern to have a service have both APIs and listening to events?

I am planning to make a service which will have simple REST APIs and will have a database in backend. I also wanted to add a logic to listen to notifications emitted by other service and there is some business logic which will update the row in the database.

For updating the database row from Notifications, I can think of 2 approaches:

  1. Should I create a API which is kind of internal to just used by service and this listener process calls this API instead of directly updating the database?

  2. Listener process directly updates the service.

I can see some pros and cons of each approach. In Approach 1, we are adding a REST API unnecessarily which is never used by clients.

In Approach 2, we are giving one backside way to reach the database instead of all the requests coming from REST API.

Can someone help me here to tell if one of them is anti-pattern and which one is better to use?

Go to Source
Author: hatellaCollege