Google Chrome. Even if func- tionalities presented by these platforms are similar, some browses can present specific features that may affect the usage of certain technologies considered for the client side. Server side: This comprises technologies typically utilized in network infra- structures. Even though they are mostly associated to a Web server, the role of a Web API client shall also be considered. The following categories apply: Web page server technologies, which groups technologies to serve Web pages such as software containers, servlets, JSPs, ASPs, and so on. These are mature technologies which does not represent a key differential aspect of the Web- telecom convergence. API technologies: The exposure of telecom capabilities in the form of Web APIs enables the offering of distributed functionalities within the Web world. In this group, technologies for implementing the serving API logic are con- sidered, and then, they are valid for implementing both the client-server and server-server scenarios. There are different options when considering how the HTTP protocol is employed and how the functionality behind the API is modeled. In the WIMS 2.0 technology map, the RPC {RPC} and REST {REST} approaches are considered. The map also considers options to encode the data exchanged between the API client and the API server, for example, XML, JSON, ATOM, and SO on. API client technologies for the server side: As previously mentioned, in the serv- er-server scenario, Web servers act are API clients, and in this particular case of the Web loom, they act as Web clients in order to invoke remote Web APIs. Technologies are those languages at the server side to rule API invocation such as PHP, Ruby, Java, Python, and SO on as well as the data formats that the specific API is utilising to encode the data exchange. As mentioned before, this is a feature of the API server and there are a variety of possibilities, most of them based on different variants of XML. Development frameworks, which includes environments geared a