REST services, separation of UI and services

Question

I am trying to learn about RESTful services. In this tutorial I am watching, the instructor states the following:

REST services keeps things very defined between what is UI vs what is Services.

• In general, what is the author implying here?
• The services used within the UI are easy to spot vs. the rest of the UI?
• Would the rest of the UI be CSS, HTML, and maybe some data stored in the local application?
• Why does there need to be clear distinctions between the UI and services?

Do you know of an existing example of this I could take a look at to better visually understand?

Answer 1

It's probably impossible to explain exactly what a single sentence from a larger extract means without the context within which its embedded. But I'll have a go anyway. I suspect there was an element of hype involved - there's no guarantee that a Restful API is any more well-designed than a non-restful API and so there's really no guarantee that it will better enforce the separation between UI logic and business logic which we'd all love to see.

However, Rest's document centrism, its focus on statelessness, and its use of a uniform API do help in creating a clean layer between the UI (webapp or mobile app) and the server.

Other forms of service oriented architecture, such as RMI or SOAP, tend to be more focussed on providing a means of accessing a remote API as if it was local - in essence hiding the fact that a load of networking-stuff is happening to get that. The result is often a very fine-grained, although quite powerful, API which requires complex logic ( business logic) embedded in the client application to use properly. These protocols can be quite chatty and network-inefficient because the focus is rarely on that data travelling over the network.

Restful APIs, which are centered around documents, tend to push UI designers in the direction of editing those documents - focussing the UIs on presentation and leaving logic either to the user or the backend service.

The uniform interface of Rest helps focus the API on working on documents - every resource is accessed in the same way, there's little leeway to add a custom response code which can be 'interpreted' in some way by the client. HTTP is a good protocol on which to build a Restful API for this reason - the major verbs are GET, PUT, POST and DELETE.

Similarly, the statelessness of Rest pushes the UI to focus on the data it has and how it should be, rather than on providing any kind of intermediate translation or caching layer to the user. The UI doesn't have any more information than the documents it has to present to the user - nice and simple.

The real core of your question, I guess, is "why should it be like that"? And the answer to that is that it keeps things simple and flexible. Presentation logic (eg what language or timezone or number format does the user care about) should not be mixed up with business logic (how many 'foo' widgets has the user bought in the past, do they really want a 'bar' widget now, because lots of people who bought 'foo' widgets want 'bar' ones too). Those two types of things have very different reasons to change and different types of people who are good at working with the underlying code.