Virtualization technologies, Cloud (private or public), “Software-defined whatever” not only bring simplicity and flexibility to systems and communications management, but also require the full automation of company IT systems.
For a number of years now we have been constantly bombarded by the idea of the cloud, where there is room for virtually everything, whether it is a private cloud or a public one, with servers installed at the client’s head office or in large data centers around the world. When moving in this world, you can never forget the importance of using technology that is as standardized as possible in order to avoid getting bogged down in tedious configurations when deploying your services.
That is why several years ago we saw the birth of technologies like REST, now widespread. REST (Representational State Transfer) is a style of software architecture that defines a number of key features when it comes to exchanging data with a web service. Broadly speaking, it takes advantage of a series of existing protocols and technologies in order to achieve this. This description makes it one of the dominant architectures in the online market, used by thousands of large companies, including, among others, Amazon, eBay and Microsoft.
REST is an architectural style for information exchange, not a standard, and the term was coined by Roy Fielding in his doctoral dissertation.
This article does not seek to give a lesson on what constitutes an existing REST architecture. Nor does it attempt to explain the features required to develop a RESTful application, or how to simply be REST-like or suchlike. Rather, it attempts a brief outline of the implications of the use of this architecture and the benefits stemming from its implementation and exploitation in a production system.
What makes REST one of the currently favored architectures for the exchange of information between client and server?
The main feature of this protocol is the exchange of messages between clients and servers without any state being held. In contrast to other protocols in the web services market, with REST the message already includes all the information necessary so that the participants of the conversation do not need to know the state of that message in advance, thus removing the need to exchange state messages and perform other intermediate operations.
REST-based applications often use the HTTP protocol to transmit the information. This, and the fact that no state is held, ensures maximum standardization of data exchange, which is a huge advantage in the implementation and maintenance of such applications. Given my experience in the world of cloud computing in recent years, and the type of corporate clients and SMEs in today’s market, I will now attempt to list the features that I believe are most beneficial:
- Scalability and load balancing: Virtually everything today is service oriented, taking advantage of the benefits of what we call cloud computing. This is, in the case of a public cloud and very broadly speaking, the leasing of a logical space for data processing and data storage from a service provider. It is usually very difficult to obtain a clear idea of the demand for the service in advance. For this reason, certain automatic or manual mechanisms are used to add new physical or virtual instances that run in parallel to provide the service. In this case, by not storing the state in the server, REST allows the client total transparency of the operation without really needing to know what server they are connecting to at a given time.
- Use of standard protocols: The massive and impressive advantage we gain from this architecture has led it to be commonly associated with HTTP. When deployed at the client’s premises, especially the corporate client’s, with countless departments (systems, communications, perimeters…), the use of something as standard as HTTP (with its ports and standard headers) means that you hardly need to reconfigure anything in the network for the program to work. Firewalls, IDS, anti-spam, antivirus protection, web reputation, everything tends to be prepared to recognize this type of traffic and web traffic generally.
- Security: When referring to HTTP, we are indirectly referring to HTTPS. Simply adding a certificate to our server, we upgrade to the safety standard par excellence for data exchange in web browsing.
- Agility and efficiency: Based as it is on a standard protocol, agility greatly increases in both exploitation and development. Any client can connect to the server, programmed in any language, and there is no need for special configurations and structures that are part and parcel of other architectures. Java, C/C++, C#, Python, Perl… Virtually every programming language barrier disappears when you use HTTP technology to transport something as simple as a “hypermedia”, like an XML. Furthermore, the reference to the different functionalities published in the server is done via the request URI, reducing traffic as it is self-describing, as well as adding headers to transmit information without having to send additional messages.
- Use of network optimization intermediate technologies: HTTP web traffic can be processed by all kinds of intermediate mechanisms, such as, for example, proxy servers, including among them cache and others with security policies. The ability to encapsulate this information in HTTP means that this architecture can interact with other intermediaries with very little effort. These intermediaries let you add an extra degree of optimization and securitization to that already existing in the architecture.
There is a great deal of documentation on the web about the benefits of this architecture over others, and here I have only named a few in passing without going into technical details. It is also important, though, to consider the disadvantages. The biggest one, in my view, is precisely what makes this architecture advantageous, that of maximizing the use of standard protocols and technologies. HTTP/HTTPS is the quintessential information transfer protocol and, therefore, the most tempting. At times it is vulnerable to hackers, especially when you are using a cloud-oriented service. Correct information encryption mechanisms must always be used to avoid uncomfortable situations such as identity theft, credential theft, etc. The developer and also, to a large extent, the client have ultimate responsibility for ensuring a secure message exchange, especially when it comes to services that can operate on an external supplier’s network.
REST: Teldat’s centralized management moves towards convergence
In Teldat, we have been actively working for a number of years on the development of new technologies to manage, not just our physical devices, but all the functions that these devices offer, from Wi-Fi management to the management of applications in corporative routers.
The main idea is to offer our customers this service in the cloud. In order to do this, we have decided to base our management communications and centralized monitoring in the REST architecture. We have also developed a whole array of security solutions on this architecture, transparent to both the user and the network administrator, to prevent potential attacks by third parties, especially when the HTTP protocol is used.
In this way, making the most of the many advantages that this architecture has to offer, we are able to create a real ecosystem where the most important features of the device, including WLAN controllers, access points, network optimization, data synchronization, etc., can coexist, and this is only the beginning. In summary, the use of this architecture allows us to easily combine our technologies with regard to the centralization of management and monitoring, its implementation being practically transparent, making efficient use of the transmitted data and making the most of the technological advantages used today for network optimization.