Are REST-based web-services more scalable then the situation of having the web-service logic embedded in a web site in terms of models and controllers (or similar)? If so, why? I have read the wikipedia article that mentions functional programming (no state), load-balancing, and cachability as reasons, but they seem to all apply to web sites (eg load-balancing). Usually the only state is whether the user is logged in or not, so isn't hard to get around.
From the perspective of REST there is really no difference between building web sites and building web Apis. The constraints apply equally to both scenarios. Therefore the scalability issues are the same.
Related
I have 2 years in the IT industry,i love to read a lot ,but when i go deep in some subjects i see a lot of contradiction in somes articles,forum or terms that are used interchangeable.
I understand the difference between Soap and Rest.
When we want to communicate between backends, we can use either of these 2 approaches, each with its advantages and disadvantages.
Situation :
If i have an application, which can be monolithic or not, where I have a backend and I will only have a front end that consumes it. Usually we create a Rest Api so that our front end can consume it. But we will never think about exposing our backend with Soap.(Lot of reasons)
Questions:
1 -Is it okay if I say that Rest , in addition to allowing us to exchange information between application and application (backend to backend ), is it also useful when exposing services for our front end? And SOAP is only useful for Server - Server communication?
2 -And finally, if I expose a backend only for a front end, it is ok to say that we expose a web service or conceptually we say that it is a backend for frontend ?
Question 1: No the First question is wrong Assumption. We can say that in SOAP, XML is the only means of communication, while in Rest, the accepted means is JSON, while there are other formats like XML, JSON, PDF, HTML etc. and Ofcourse, XML can be converted back from server into UI Language and XML Request deciphered at Server for a Response. So, its not Ok to say that SOAP is only for Server - Server Communication.
2. No, when you have typically exposed backend only for consumption by a Front end, you can typically say that it is a backend for numerous front end client requests. But IMO, Backend for a front end is a monolithic webapplication, both bundled in WAR. so in that sense, any UI Request can request response from the Back end web service. Hope i am able to clear your understanding about web services.
I see that in your question there are actually 4 embedded independent topics. And probably because they are always used in conjunction it is sometimes tough to understand.
I will give a short answer first:
REST and SOAP both can be used for Client-Server and Server-Server integrations. But the choice will be dependent on the questions like where you want server-side UI technology/client-side UI technology or is it a single page application/portal technology, etc.
If you expose a single-backend for a single-frontend it's technically a BFF although the term BFF is used only in the case where you have separate-backends for each type of frontend application. e.g. one for mobile, one for web, one for IoT devices, etc.
The long answer is to clarify the 4 principles. Let me give a try at this by separating the topics into the below four headings:
1. Backend(Business Layer) vs Backend for frontend(BFF)
In classical 3-tier architecture (UI-Business Layer-Database) world, the middle-layer that consists of the business and integration logic is mostly referred to as backend/business layer.
This layer can be separated from the UI/Frontend using multiple different options like APIs(REST/SOAP), RPC, Servlet Technology, etc. The limitation with this 3-tier architecture is that, it is still tightly coupled to the type of users and use-cases are limited to web/browser based. It is not a good choice when you want to reuse the business-layer for both web and mobile as the mobile applications are required to be light-weight by principle.
That's where we lean on to multi-tier architecture with Backend For Frontend(BFF) as a savior. It's just a methodology to segregate the business-layers based on consumers.
2. Monolith vs SOA vs Microservices(Optimized SOA)
In a monolith world all the code components mostly UI and Business Layer sits in a tightly coupled fashion. The simplest example would be a Java Servlet Pages(JSP) application with Java as Business Layer. These are typically server-side UI technologies.
In Service Oriented Architecture(SOA), the usecases revolve around leveraging reusable business layer functions aka services. Here one would have to deal with UI-Server, Inter-Service and Server-Server integration scenarios. It's heavily service dependent, meaning it's like a spider-web of dependent applications.
The Microservices is an extension of SOA, but the approach is to keep a resource in focus instead of services to reduce the spider-web dependencies. Hence, self-sufficient and standalone service-clusters are the base of micro-services architecture.
3. SOAP vs REST Webservices
SOAP stands for Simple Object Access Protocol, typically used by the business-layer to provide user-defined methods/services to manipulate an object. For example look at the names of the services for accessing a book collection
To get a book getABook()
Get the whole list of books listAllBooks()
Find a book by name searchABook(String name)
Update a book's details updateABookDetails()
On the other hand, REST is representational state transfer which transfers the state of a web-resource to the client using underlying existing HTTP methods. So the above services for accessing a book collection would look like
To get a book /book(HTTP GET)
Get the whole list of books /books(HTTP GET)
Find a book by name /book?name={search}(HTTP GET)
Update a book's details /book/{bookId}(HTTP PATCH/PUT)
4. How to make a correct choice of architecture?
Spot the diversity of the application user groups and usages: This will help to understand the platform(web/mobile/IoT/etc), nature of the application and session-management.
Determine the estimated/required throughput: This will help you to understand the scalability requirements.
How frequently and who will be maintaining the application: This will help to gauge the application and technology complexity, deployment cycles, deployment strategy, appetite for downtime, etc.
In conclusion, always follow the divine rule of KISS: Keep it simple, stupid.
1.)
A webapplication is for H2M communication a webservice is for M2M communication through the web. The interface of the service is more standardized, more structured, so machines can easily use it and parse the messages.
I don't think it matters where your service consumer is, it can run in a browser or it can run on the server. As long as it can communicate with the service on a relative safe channel it is ok.
You design a service usually to decouple it from multiple different consumers, so you don't have to deal with the consumer implementations. This makes sense usually when you have potentially unknown consumers programmed usually by 3rd party programmers you don't even know or want to know about. You version the service or at least the messages to stay compatible with old consumers.
If you have only a single consumer developed by you, then it might be too much extra effort to maintain a service with a quasi-standard interface. You can easily change the code of the consumer when you change the interface of the service, so thinking about interface design, standardization, backward compatibility, etc. does not make much sense. Though you can still use REST or SOAP ad hoc without much design. In this case having a RESTish CRUD API without hypermedia is a better choice I think.
2.)
I think both are good, I would say backend in your scenario.
I understand (somewhat) what are differences between monolithic , microservices .
And also what is SOA it is a service consumer/provider architecture and microservice is subset of SOA. and they use Restfull/SOAP APIs to communicate.
So when a a request something he/she does using Rest/SOAP API but how in a Monolithic architecture a client request through which API? I searched all the links/blogs on google, videos on youtube but still I am not clear about this.
Or may be my whole understanding is not correct.
Sounds like you are a bit confused, I would really recommend you picking up a book on the subject.
Monolithic vs micoservice application is more about how you package and deploy your application and in some sense how coupled modules/subsystems are. The extreme example: you always deploy the entire monolithic applications for the smallest possible change, and in the microservice example you just need to make the same change to one service.
Rest API and SOAP are protocols for how (http) messages are passed between client <-> server and has nothing to do with monolithic vs micro.
Monolithic application can of course have public http API's, and it might not be possible for a user (sending request) of that API to tell the architecture style of that application. And why would she care about that?
I think this is a nice start: https://martinfowler.com/articles/microservices.html
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.
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.
Let me introduce you a taxonomic view of those term:
Microservices
are a subtype of services specialized by minimal responsibility.
Webservices
are a subtype of services as well, specialized by the type of service they provide wich fall under web requirements and needs.
SOA
is a subtype of architectures and hence a structural view of some components and their relationships, where happens to be services and communications between those services respectively.
rest
is a subtype of communication, underlying http protocol.
restful
is a subtype of architectures (a structural view of some components and their relationships) where specialized by relationships among components restricted to be rest communications.
In relation to this question, I have a follow up question that I am still confused over. I have been asked to compair REST vs Web Services. From what I have learnt about REST, it is not a web service, therefore how can you compair the two? What does the question mean when it says REST in this respect?
REST is an architectural pattern for web services emphasizing the usage of URIs as resources with a small set of operations that may be performed on them (usually PUT, POST, GET, and DELETE). I'm guessing you are being asked to compare REST to the ws* standard web services which utilize a lot of other technologies (including SOAP, though SOAP itself is not a web service, it is just a protocol that happens to be used in ws* web services).
REST can be used to provide web services just like databases can be used to store names and addresses. REST is far more general purpose than simply a way of providing a web API.
REST is useful for building distributed systems. However, many people use Web Services (note the capitals, this usually denotes SOAP, WS-*) for building distributed systems.
Wow, I just saw the homework tag. That is one seriously mean question. There are industry veterans who could not come close to answering this question.
A more accurate question would be: Compare REST using HTTP versus RPC using SOAP for building distributed systems.
They probably mean REST verse SOAP. They're all web services in concept.
The abbreviation REST stands for "REpresentational State Transfer".
REST APIs are used to call resources and allow the software to communicate based on standardized principles, properties, and constraints. REST APIs operate on a simple request/response system. You can send a request using these HTTP methods.
Hence REST is just an API (an interface that allows you to build on the data and functionality of another application) architectural style.
On the other hand, web service is a network-based resource that fulfills a specific task. Yes, there's overlap between the two: all web services are APIs, but not all APIs are web services.
GUI based web applications could be build upon a GUI component, stateful framework like Wicket or they could build in a RESTful, stateless way with GUI status only on the client.
From a technical point of view REST looks like the right way since it leverages the full power of http and leads to highly scalable applications. But that comes at a price. Complex GUIs will require a JavaScript application on the client in many cases. You have to stay on the same page and reload only parts, if state should be maintained on the client. Or you have to use tricks with hidden iframes. Sometimes there are pseudo resource like shopping carts on the server, to enable a RESTful design. You have to maintain intermediate state of multi step dialogues and so on ...
If I look around there are very few RESTful GUI webapplications. Is this because of historical reasons or is a RESTful design unproductive in common scenarios?
If I look around there are very few
RESTful GUI webapplications. Is this
because of historical reasons or is a
RESTful design unproductive in common
scenarios?
My answer is subjective, but in my opinion, two major hurdles hinder RESTful development:
Change - it very different from the way sites are traditionally designed
Challenge - designing a pure RESTful server API and a corresponding rich, robust client UI isn't easy
Complex GUIs will require a JavaScript
application on the client in many
cases.
In my opinion, a complex, a rich client-side experience is going to require some in-depth JavaScript, regardless of the server-side implementation.
You have to stay on the same page and
reload only parts,
This is a very different design from the traditional request/response full-page-to-full-page design. Each design has its own trade offs. REST designs work particularly well with AJAX calls, but the client-side code requires careful design to be maintainable and robust.
A RESTful server with a thick-client:
scales well: session information for every user isn't stored in scarce server memory
less request/response data over the wire: not sending every page in full, not sending session IDs or ViewStates
clean reusable URLs: provide a clean, decoupled server API that can support multiple UIs
pure: strict adherence to the HTTP specification (GETs cause no side effects, etc.)
client experience: richer, more responsive with asynchronous transactions
However, as you mentioned thick-clients have drawbacks:
more vulnerable to XSS attacks, RESTful URLs really need careful security
complex JavaScript can be challenging to develop, maintain, and debug (using OO JavaScript can help mediate this)
there is a need to indicate to the user that asynchronous requests are processing in the background
more client-side failure-handling logic is required
frameworks and IDE tools have been traditionally weaker for client-side development, compared to server-side (this is slowly getting better)
RESTful GUI designs are very productive, IMHO. You can leverage a lot of functionality without extra work to support the corner cases, such as the user resubmitting information, browser history (back and forward) multiple tabs and windows. If I'm not mistaken this site uses a RESTful UI.
REST was defined by observing characteristic of successful web applications, both GUI and M2M. Therefore by definition it should be appropriate for these cases.
I also noticed you asked a question regarding desktop versus web applications. You may be interested to know that REST is an excellent architecture for building desktop client applications too. I have written a few desktop clients that get all of their data from a REST server.