The tools and IDEs created a very pleasant developer experience, which we all liked. JSON was a huge step back in consistency and standardization, but an even greater leap toward simplicity for the majority of developers. It works very well, almost magically, when the client and server are created using the same toolkit but it is not that great when two different technologies are used, however it is still acceptable. Support for all the development platforms arrived quickly and today it’s almost invisible, as we just create server APIs and clients consume them without any problems. eval function (security nightmare at the time). JSON was selected because it was very easy to be parsed by Javascript client (browser), initially even with a simple. Most developers followed along, but in reality the workflow required you to try and call the API to see if it’s working, how it is working, and how it is behaving when something goes wrong with the call arguments or server side error. For instance, you would use GET to read operations, while POST and PUT to ‘write/update’ operations, etc. There were no standards really, as they were more like conventions. It was not even supposed to be a RPC, but many other technologies became RPCs, and eventually so did REST.
Of course the idea of REST was totally different. This idea was to forget the other protocols and just send the requests and responses over the http protocol using different http verbs (GET / POST / PUT) to perform different operations. There were benefits such as cross platform compatibility and explicit contract definition, but the development community was in search for something simpler.
However, it was not very well liked by developers, because of all the contracts, heavy XML payloads, parsing, and the hell of XSLT (XML transformation language). Huge XML payloads of the early 2000’s marked this era in the software’s history. Especially in the scenarios when standardized end-to-end message security is required like communication with the tax office, there are many B2B exchanges. SOAP was well supported by all major programming languages and is still in use today. Simple Object Access Protocol (SOAP) dominated the early 2000’s and delivered on the promise of an API contract independent of the programming language and transmission protocol. This isn’t a software history article, but we have to mention Corba, Java RMI, and dotNET remoting, but having done so, let’s quickly move on to SOAP. RPC is when we call a function and the function does not execute in our process, but remotely on a different machine (or different process on the local machine). The concept of remote procedure calls (RPC) is very old, but is always key for building distributed systems and will continue to be so.
0 kommentar(er)
