Swagger For the REST of Us

In the last few years, RESTful web services have become as ubiquitous as SOAP in the early 2000s. You look anywhere in the tech community, you will notice someone somewhere is either talking or doing something with REST APIs or microservices. In spite of its immense popularity, REST lacks any type of standard other than a few guiding principles. REST doesn’t have anything similar to Web Service Definition Language (WSDL). WSDL is used for describing SOAP operations, messages, and also for generating client code.



REST API and Error Handling

Most developers don’t think of errors and exception handling while designing a REST API. However it is very critical from your API user perspective as the whole logic inside your API code is black boxed from them. If your API returns an error, the API user should be able to make sense of it so as to take any corrective action.


Dockerize your REST API

If you are in IT field, you must have come across the term Docker. Docker is still very new and gained traction in the last year or so.  So, what is Docker? Docker is a open-source platform that allows you to run your application image in a virtual environment. There are two parts to Docker – image and container. An image is a file that contains a stripped down version of Linux OS along with your application and all its dependencies. While container is a running instance of an image. The Docker Engine provides the technology to create the image for your software and also to run and manage the container. You can find more about Docker here.


REST with Spring

Spring relies on its Spring MVC framework to support REST APIs. The concept of Model-View-Controller (MVC) was introduced in the the seventies at Xerox Parc. MVC pattern makes an attempt to modularize software by isolating different functional units from each other. It separates application domain/data (model) from the display of the application state (view) and the interaction with the model and view (controller).


Toying with Togglz

Any non-trivial software is composed of many different parts. Some of these parts can be grouped together to form a software feature – a unit of functionality that satisfies a requirements or business needs.

In today’s agile environment, a release cycle is decomposed into multiple sprints. The basic premise of sprint is to build a product which is ready to be shipped at the end of each sprint cycle – doesn’t matter if the product has only a few basic functionalities. What happens to those features which take multiple sprints to build and are not ready to be released yet? It’s important to remember that the incomplete features are still part of the same codebase.