Why do we need service layer?

You don't always need a service layer. Especially if your APIs are just simple CRUD operations, for example, with no real logic required or calculations.

However, if you have an API which performs some logic before querying your repository then this should be in a separate service class. This is good practice arising from what is known as the single responsibility principle.

https://en.wikipedia.org/wiki/Single_responsibility_principle

• Your Controller's single responsibility should be to handle theincoming request.
• The Service layer's single responsibility is to do any logic required with the data received by the Controller.
• The repository's single responsibility is to query the data base.

Layered architectures are generally suypported by this contention:

We use layers to allow us to abstract away the underlying implementation so we that we can easily change it.

A happy side effect of layering is that - if followed faithfully - it can make the system more testable by (a) using interfaces to define each layer and (b) encouraging separation of concerns.

So, that's the principle (briefly, at least) but like any principle it can be misunderstood and misapplied.

While the benefits of layering to hide data access from the view layer (and vice versa) are solid in most cases, the benefits of including a service layer between the view layer and the data layer are not always so compelling. A system which has ...

• A small number of controllers
• A small number of repositories
• A 1:1 mapping between controller and repository
• No need for complex transformations between domain representations (for repositories) and view representations (for controllers)

... probably doesn't need a service layer.

Whereas, a system which has ...

• Large numbers of controller and repositories
• Complex relationshiops betwen controllers and repositores e.g. maybe a controller uses multiple repositories and combines their results or invokes these repositories in a chain
• Complex transformations between domain representations (for repositories) and view representations (for controllers)

... probably does need a service layer.

Thats a way to separate service functionality from transport, your service defines a functionality that cover a single responsability (SOLID), and that can be exposed using different ports (Hexagonal Architecture), for example HTTP/REST or AMQP.

Adding a service layer give you the flexibility to change your port in the future, or use more than one.