Monday, 24 July 2017

An Introduction to REST and JSON

Currently, the vogue is JSON-based services over XML/SOAP. In addition, RESTful services are also in style over WSDL-based services, especially for basic data operations (CRUD), although depending on the language and web stack, this isn't as big a deal.

JSON is short for JavaScript Object Notation, and is a way to store information in an organized, easy-to-access manner. It is used primarily to transmit data between a server and web application, as an alternative to XML. In a nutshell, it gives us a human-readable collection of data that we can access in a really logical manner.

JSON is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.

REST stands for Representational State Transfer. It is a stateless software architecture that provides many underlying characteristics and protocols that govern the behavior of clients and servers. REST is a web standards  based architecture and uses HTTP Protocol for data communication. It revolves around resources where every component is a resource and a resource is accessed by a common interface using HTTP standard methods

A REST service has a few advantages over a more traditional WSDL-based service:

* The completely URL-based resource request hides the sausage-making behind the scenes of a modern dynamically-generated website or service pack, so your URLs are cleaner (and somewhat harder to hack in a harmful way)

* The URL-based navigation also makes navigation of your REST API from within a browser easier; in fact, Quora itself uses REST to serve up the actual pages, in addition to an AJAX layer providing live updates. The resulting resources are easily bookmarked or permalinked without you having to actually have a page in your website for each resource.

* REST uses the actual HTTP action verbs (GET, POST, PUT, DELETE, OPTIONS) to expose and define functionality available for a single resource, giving you more for "free" on the client side and providing a more intuitive, standardized way for clients to dynamically construct a service request.

JSON also has a few advantages over XML for the average use case. JSON is more lightweight (fewer markup characters required), more easily parsed by web clients (it's JavaScript Object Notation, after all; it's used to declare/instantiate objects in JavaScript code so it's very easily parsed), and more human-readable. However, as JavaScript is effectively a dynamically-typed ("duck-typed") language, where almost everything is just a "var", JSON data does not include type information by default.

When developing a new service that you expect to be consumed by third parties, and you put the question to them, those third parties will virtually always vote for REST and JSON.

Tuesday, 18 July 2017

Microservices Architecture

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. Each module supports a specific business goal and uses a simple, well-defined interface to communicate with other sets of services.
Microservices Architecture

Microservices pros and cons
This solution has a number of benefits:
  • Each microservice is relatively small.
  • Are easily deployed.
  • Require less production time.
  • Can scale quickly.
  • Can be reused among different projects.
  • Each service can be developed and deployed independently.
  • Complement cloud activities.

However, there are also drawbacks with microservices, such as:
  • Potentially too granular.
  • Latency during heavy use.
  • Testing can be complex.

Microservices, on the other hand, require little of centralized management. Microservices applications are independently deployable and scalable. They enhance business capabilities with less planning and production than monoliths.