Should a REST API reflect server-side application architecture

Question

I'm in the middle of writing my first web app. Just wondering how the conventions are when it comes to REST API designs. Is it better to have it reflect my server side architecture or whatever seems to be easier to reason about?

I'm thinking of either doing:

/serviceProvider/product

or

/product/serviceProvider

My server side architecture are all separated into modules organized by service providers, however they all expose a product query API.

Answer 1

APIs ideally should be designed to make most sense for its consumer. There isn't really a good reason to reflect your "server architecture" at all. In fact, it's what's usually called a leaky abstraction or a leaky API and is considered bad practice, mainly because your application structure may change and then you have these possible scenarios:

• you need to change your API, which is a non-trivial task when it's already being used by someone;
• your API stops being reflective of your application structure which leads to inconsistencies;
• exposing your application structure or database schema to the world may have security implications.

With these things in mind, you might as well design the API with focus on ease of use in the first place. The consumer of your API doesn't need to know or care about your application architecture.