All geek questions in one place

If the REST API reflects server-side application architecture

I am in the middle of writing my first web application. It's just interesting how conventions are made when it comes to REST API design. Is it better to reflect my server-side architecture or something that is easier to talk about?

I think about this:

/serviceProvider/product

or

 /product/serviceProvider

My server-side architecture is divided into modules organized by service providers, however they all expose the product request APIs.

+5
source share
2 answers
APIs

ideally should be designed in such a way as to make the most sense to the consumer. There is no really good reason to reflect your "server architecture" in general. In fact, this is what is commonly referred to as leaky abstraction or 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 is already in use by someone;
  • your API is no longer a reflection of the structure of your application, which leads to inconsistencies;
  • Revealing the structure of the application or database schema in the world can have security implications.

Based on these considerations, you could also develop an API with emphasis on ease of use in the first place. The consumer of your API does not need to know or care about your application architecture.

+5
source

I believe that maintaining the same architecture is important because you are forced to offer a simple API, and this will provide you with a simplified server-side architecture. However, of course, you do not want to disclose any method on the server side or even each property on the side of the returned objects.

At Kaltura, we also believe in flat (non-nested) ways to simplify the API. For more recommendations, see my blog: http://restafar.com/create-new-rest-server/

0
source

Source: https://habr.com/ru/post/1237900/

More articles:


All Articles