A useful thread is about layers vs tiers here:
From a simplified physical point of view we have the client(browser), application server, db server.
From a logical point of view we might have different layers(again simplified): web, business logic, data.
The idea of layering is to have first separation of concerns(presentation, business logic, persistence, etc.) and the higher layer can call only the immediate layer below(so in the example before web layer can call only business logic, it should not call the data layer). Nice thing about this is that each layer has an interface which is exposed without any implementation details(code to interface pattern) so you might swap the implementation of the layer. So now you might store the data in a relational DB but you might create a new implementation which store the data in a NoSql db(you don't need to change anything of the business logic layer). So you have the same data layer but different implementations.
In a traditional java web app the code is deployed in the application server and the output of it(servlet) is usually a HTML which is displayed in the browser.
So the presentation layer(formatting and so on) is done on server side for each client(request). Having clients in the application server we have a session, so a state for each client(e.g: the language data is displayed, the corresponding date format and so on).
REST architecture make a change because it promotes stateless operations. One of the consequences of this was to move any client related coding in the browser(emergence of javascript web frameworks) with the session variables and than the web layer returns a JSON/XML instead of HTML.
To answer your question you might have a different web layer on top of the business logic. One might return HTML one might return JSON(think about it as in the example with the data layer).
