What exactly is functionality and presentation of SOA?

Question

Looking for answers on what exactly REST is, I came across a post on SOA on stack overflow:

"magine you are developing a web-application and you decide to decouple the functionality from the presentation of the application, because it affords greater freedom. You create an API and let others implement their own front-ends over it as well. What you just did here is implement an SOA methodology, i.e. using web-services"

As far as I understand, this is saying that SOA is an umbrella term for designing software in such a way that functionality and presentation are separated (is that not MVC?). And that REST is a means of doing that.

What is the functionality, and what is the presentation is this case?

I understand REST as an architecture for designing server side code that creates URI links as included in the HTML on a browser, and that processes stateless server requests. Is this correct? and if so, what is the alternative to this?

What exactly would a server request that isn't stateless be?

Here is the original question: JSON, REST, SOAP, WSDL, and SOA: How do they all link together

I don't know if my question makes sense, I'm quite confused.

Answer 1

As far as I understand, this is saying that SOA is an umbrella term for designing software in such a way that functionality and presentation are separated

Yes, that is the goal. But SOA implies a particular approach to that goal where the different parts of a system are actually separate programs, communicating over some API. Each of those parts might be in different programming languages, or on physically separate hosts.

(is that not MVC?)

MVC is a way of structuring a single program by breaking up its code into reusable units. But a Model object is only useful if it can be passed around the application, you couldn't run it as a separate program. You could, however, write an MVC program that was one of the components in an SOA system - e.g. consuming an API in a particular way and turning its results into model objects, then passing them to an HTML view.

I understand REST as an architecture for designing server side code that creates URI links as included in the HTML on a browser, and that processes stateless server requests. Is this correct? and if so, what is the alternative to this?

Not quite. REST has nothing to do with HTML, only HTTP: rather than using a wrapper like an XML document which says "I would like you to do action X, here is the input Y" (which is roughly what SOAP does), REST uses the URL and the type of HTTP request (GET, POST, PUT, DELETE) to describe what's needed. It comes with a philosophy that the object of an action (e.g. /user/42) is more central than the specific verb (e.g. ResetPassword)

What exactly would a server request that isn't stateless be?

HTTP itself is a stateless protocol, but that doesn't mean you can't build stateful applications on top of it. For instance, by using cookies, this website is maintaining the state that I'm logged in to credit me for this answer. In many APIs, some form of session identifier is passed with each request so that you can, for instance, build up a basket of items prior to booking. This can simplify the use of the API, but restrict the order in which operations can happen. A RESTful approach might instead let you create any number of baskets and retrieve them at any time, leaving an action such as searching for a product to be truly stateless.