what are REST,RESTFul, SOA and microservices in simple terms?
I thought I knew what REST/"RESTFul", restfulservices, webservices, SOA and microservices were but I came across so many different definitions that I reached the conclusion that those terms are overused, misused , or simply badly defined.
I hope to have a clear understanding of what the aforementioned terms represent, their concrete definition , their commonality and differences, advantages vs disadvantages, and most importantly the bottom line - the most important things to remember in order to use those terms appropriately.
Answer
Disclaimer: most of this post is subjective. No attempt has been made here to strictly define anything, just trying to contextualize and give a global overview of the concepts and how they relate to each other.
I thought I knew what REST/"RESTFul", restfulservices, webservices, SOA and microservices
I'd say that all these terms fall into the umbrella of Service Oriented Architectures (SOA). Web services is a SOA using web-related technologies. REST and its subset RESTful are a set of practices to implement web services. Finally, microservices are a new set of SOA practices.
I hope to have a clear understanding of what the aforementioned terms represent
I'll try to address this point, but using informal definitions and without entering into advantages and disadvantages. That'd be way too long and I think the biggest points should be obvious from the explanations.
SOA
I think the name is self-explanatory in this case: SOA -- which stands for Service Oriented Architecture -- refers to architectures designed with a focus on services. Now, the tricky part here is what you may or may not consider a service and that is a whole different topic.
Web services
This accounts for the subset of SOA using web-related technologies. This typically involves HTTP and XML but it could also use FTP. I think the term web here is quite vague as it generally refers to standard Internet technologies.
REST(ful)
REST is a subset of web services -- and hence a SOA -- that revolves around using HTTP for communication. There are a certain set of common practices such as a certain given relevance to URLs.
About 10 years ago when I was introduced to REST, RESTful was presented to me as a more strict REST implementation where a resource would have a unique URI and it would be managed through CRUD operations mapped to HTTP verbs -- Create = POST, Read = GET, Update = PUT, Delete = Delete.
Updating user information through a HTTP GET or POST request o a /users/1/update URL would be perfectly valid in REST, but it would not be RESTful. For the latter, the approach would be to use an HTTP PUT or PATCH over /users/1 (which would also be the URL for the rest of the operations, simply varying the HTTP verb).
I find that this distinctions has become blurred over the years. However, it still stands that RESTful is a more strict subset of REST. (The exact requirements may be debatable.)
EDIT - A more formal definition:
REST stands for Representational State Transfer and was presented by Roy Fielding in his Ph.D. thesis as an architectural style for distributed hypermedia systems. The emphasis goes into the hypermedia and self-containment decoupling the client from most beforehand knowledge among others. A website is an example: it consists on a single URI (the website root) and a media type (HTML) through which the server offers all the information a client needs regarding resources and all possible interactions.
I'd say 99% people talking about REST really mean RPC or HTTP-based interfaces: using HTTP endpoints to invoke certain actions or query data. Fielding himself has tried to clarify this. Any API formed by a set of predefined URLs expecting certain HTTP verbs and some parameters falls into that 99%. So does my description above. However, I doubt the term itself can ever survive its misuse and I think we must accept its new meaning.
Microservices
This is the more recent term; it promotes implementing applications as a set of simple independently deployable services. This contrasts with the classic approach of SOA architectures as a set of quite complex services used to build complex systems, tipically involving an enterprise service bus. However, it is important to note that although typically SOA gets associated with such systems, it is a broader term and indeed, microservices are also a subset of SOA.
Microservices usually appear hand-by-hand with modern JavaScript full-stacks -- i.e. using JavaScript for all the vertical components, from the server up to user interface. Arguably this is so because using these JavaScripts full-stacks may speed up development thanks to the simplified integration. These stacks, and hence microservices implemented using them, are usually architected through REST but from a theoretical point of view, there is nothing preventing you from using a different approach to the same philosophy.