In the current project, let "toys" be the category and "gun" be the product. The ID for the toys category is 2 and ID for the gun product is 1.

The URI for categories is /api/v1/categories/<category_id>.

The URI for products is /api/v1/categories/<product_id>.

So we have the category toys at: /api/v1/categories/2 and we have the product gun at: /api/v1/product/1

For deleting a specific product, we have to make a DELETE request to the specific product URI, e.g. DELETE /api/v1/product/1.

But for creating the product, we have to go to /api/v1/product/2 and create a product with a name, and price, and the product resource ID (2 in the given URI) is actually the category ID.

So in this example, if I use .../product/2, then the product is created under the toys category as toys is the category with ID 2.

But I raised an objection and recommended that to create a toy under a category then the POST action should be under that category. In this example, for creating the product, we have to go to /api/v1/categories/2 and create a product with a name, and price and the product will be created in the toys category.

But the developer insists that the implementation is correct, and it is a REST API and so the HATEOS for creating a product will be pointing to the /api/v1/product/<category_id> so there is no need to do this under category resource itself.

As a QA what should be our response to such a design ?

Should it be ignored or are there are any good practices QA follows to ensure the quality of a REST endpoint?

What would be a good checklist for REST API validation ?

  • 1
    No you are correct. Product is product and category is category. The current design is mixing concerns which is a code smell. The return of each api call should only return that type of thing. – John Peters Mar 26 at 4:35
  • \@JohnPeters thank you for the reply. Hope i will be able to communicate this properly with the management – PDHide Mar 26 at 7:38
  • 1
    The category ID should only be in the URL for creating a product if it's a nested resource, POST .../categories/:id/products. I don't think either of you is correct in the current structure: creating a product should be POST .../products with the category ID being in the payload, as it's part of what defines the resource. – jonrsharpe Mar 26 at 8:23
  • If a product is being created it should be Put to product where category id is in payload.. there's no need to overcomplicate – John Peters Mar 26 at 10:31
  • 1
    That feels like a matter for your specific organisation. What feedback do they want from you? What does quality mean here, beyond the API working as documented/intended? You need to agree this as a team, there aren't general answers. – jonrsharpe Mar 26 at 13:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.