Alberto Corrales Garcia

Introduction In the era of Microservices, you are probably designing or consuming one or more Web Services. As a result, you might be aware of the importance of having a good definition of your web services, since that is what clients and developers will use to know how a web service can be used. For that reason, you should have a clear and easy way to define and understand your Web API. In order to help you to make a good definition we have REST (Representational state transfer) , which is a software architectural style that defines a set of rules to create Web Services. I'm not going to go into details about RESTful, because there is enough material for a full post and it is out of the scope of this post. But I might write another post about REST, since even nowadays I see some crazy stuff when it comes to Web APIs design. Well, imagine we already have a really awesome definition for the resources of our Web API, and your clients are going to be really excited to use it,

Introduction Since I started my career in Computer Sciences, I have had the chance to work with a huge variety of frontend and backend technologies. During that period, on the client side, I witnessed how the web has evolved, starting static html, then adding javascript, AJAX, later animations with flash, silverlight or applets, html5 and recently new frontend frameworks like Angular, Vue and React.....or the incoming and promising Blazor, of which I will talk in a future post. So Javascript at the beginning was created to add some scripting capabilities to our static websites, which most of the times led to a lot of spaghetti code difficult to maintain. Ajax was also an important turning point, which allowed us to render our page dynamically, instead of having that ugly user experience produced by server-side rendering frameworks, such as MVC, JSP or PHP. And this fact moved the logic for web pages from server to client, producing a great client experience. However webs become c