Confusion about layered architecture

There are different understandings of the presentation layer.

The traditional layered architecture that you describe predates the internet and in fact originates from the three tier architecture model. In this view:

• the presentation layer corresponds to the client component that offers the user interface and communicates with a backend which runs on an application server.
• the rest API is the interface between presentation and business logic. The consuming part of the interface belongs to presentation. The producing part of the interface belongs to the business logic. It’s the service sublayer that exposes the business layer to the outside world.

The more recent MVP architecture is an adaptation of MVC that was triggered directly by the emergence of the internet. It sees it differently:

• the business logic is part of the M (model) and the DAL is a sublayer of M that ensures persistance.
• the font-end user-interface is the V (View) for the displaying
• the P (presentation) is the component in the middle, designed to be split between front-ent where it takes charge of the user-input (similar to an MVC controller) and the queries (coming from V), and the back-end (where it dialogues with M, and acts as a local controller and as a proxy for the remote V and C). In this analysis, the REST API belongs completely to the presentation component.

MVP is not mutually exclusive with layering: M is in general layered in order to distinguish the BLL and the DAL, but in this case there is an ambiguity about what the presentation really refers to.

You are therefore free to decide in which layer you want to see your REST API.

Personally if I’d use a classical layer scheme to describe my architecture, I’d prefer to be consistent and split it according to the three-tier decomposition.

But, if you consider your REST API to be part of the presentation, because it already presents the data in HTML, you’d not be wrong: you’d just analyse it according to an MVP decomposition of responsibilities. But I’d then advise to make a clean cut between the back-end and the front-end part of the P, and to ensure a clear separation of very different concerns.

Not related: another question is whether you want to continue to see the world in classical layers, or if you’d prefer a cleaner architecture

A presentation layer is a presentation layer regardless of how the rest of your app is built.

You mention single page web apps (spa), rest, angular, spring, n-tier, etc. but a presentation layers job is still the same: combine data with a way to consume it.

That might be visual, auditory, or even tactile. It might be a GUI, a console, printed paper, plotter, web, an audio speaker, IP socket, or a fireworks display.

Each of those has needs that don’t need to be represented in the model. The presentation layers job is to transform data from the model into something that meets those needs.

Thanks to having a presentation layer the model can be free of knowledge of how data is presented. Ideally the same model can be presented many ways.

Presentation differences can be more than media. Key value pairs can be converted to graphical displays showing named positions on a map. Both forms could be presented to a GUI, a print out, or even a console (with a little ascii art).

The back end tech doesn’t change any of this. It does make some forms easier than others but the basic idea remains the same.