Forem: Amrinder singh

Anatomy of REST API

Amrinder singh — Mon, 30 Sep 2019 06:09:31 +0000

What is REST
REST (Representational State Transfer) is an architectural style for designing network applications, driven by a set of constraints and inspired from the architecture of the Web.

REST and HTTP
In theory, REST is entirely separate from the HTTP protocol, but in practice, we're primarily building APIs on top of HTTP. So the goal is to leverage the full semantics of the protocol and use it as an application protocol.

REST Constraints:

Constraint 1 - Client-Server
This fundamental constraint enforces a separation of concerns and enables independent evolution of the Client and the Server.

Constraint 2 - Stateless
The communication between Client and Server must be stateless between requests.
First - the obvious part: each request from a client should contain all the necessary information for the service to complete the request.
Then, the more non-obvious part: all session state data should then be returned to the client at the end of each request.

Constraint 3 - Cache
All responses from the Server should be explicitly labeled as cacheable or non-cacheable.
Requests should pass through a Cache Component - which can partially or fully eliminate some interactions with the Server.
The results are improved efficiency and scalability by matching and utilizing the already available huge infrastructure of the Web.

Constraint 4 - Interface / Uniform Contract
The Service and all Clients must share a single uniform technical interface.
In order for that interface to be reusable by a wide range of Clients, it needs to provide generic, high-level capabilities that are abstract enough to accommodate a broad range of interactions.

Constraint 5 - Layered System
This constraint builds on Client-Server Constraint to allow for Intermediaries / Middleware.
These intermediaries must be fully transparent for the Client.
The interaction between a Service and a Client should be consistent, regardless if the Client is communicating directly with the ultimate receiver of a message or not. Similarly, the Service does not need to be aware of whether the Client is itself acting as a service for other Clients or if it's the actual origin.
This kind of information hiding greatly simplifies the distributed architecture of the system and allows individual architectural layers to be deployed and evolved independently of specific services and consumers.

REST Terminologies:

Terminology 1 - Resource
The Resource is the key abstraction of information in REST.
Any information that can be named / identified via a unique, global id (the URI) - is a Resource.

Terminology 2 - Representation
Any given Resource can have multiple Representations; these capture the current state of the Resource in a specific format.
At the lowest level, the Representation is "a sequence of bytes, plus representation metadata to describe these bytes".

Terminology 3 - Hypermedia Types
There are several Hypermedia types we can use for our Representations, and we can build our own if we need to.

Builder Design Pattern

Amrinder singh — Sat, 10 Aug 2019 09:32:06 +0000

What is it?
Builder is a creational design pattern that is used to construct a complex object from simple objects using a step-by-step approach

Real World Analogy:
If you have ever been on Tesla website you must have seen they have a step by step way of selecting a car that starts from a base model and user can keep on adding features as they want. This can be handled in code by telescoping a constructor and having all the possible combinations but what if a new feature is introduced.

Solution
The answer is Builder design pattern. The Builder pattern suggests that you extract the object construction code out of its own class and move it to separate
objects called builders. Instead of telescoping a constructor to handle all the cases we build the car using features selected by a user.

Code Example:

public class Director {
    BuilderInterface myBuilder;

    public void construct(BuilderInterface builder) {
        myBuilder = builder;
        myBuilder.buildBody();
        myBuilder.insertWheels();
        myBuilder.addHeadlights();
    }
}


public class Product {
    private LinkedList<String> parts;

    public Product () {
        parts = new LinkedList<String>();
    }

    public void add(String part) {
        parts.addLast(part);
    }

    public void show() {
        System.out.println("\n Product completed as below");

        for(int i = 0; i < parts.size(); i++)
            System.out.println(parts.get(i));
    }
}

public class Client {
    public static void main(String [] args) {
        System.out.println("***Builder Pattern Demo***\n");

        Director director = new Director();

        BuilderInterface carBuilder = new Car();
        BuilderInterface motorBuilder = new MotorCycle();

        // making a car
        director.construct(carBuilder);
        Product p1 = carBuilder.getVehicle();
        p1.show();

        // making a motorcycle
        director.construct(motorBuilder);
        Product p2 = motorBuilder.getVehicle();
        p2.show();
    }
}

interface BuilderInterface {
    void buildBody();
    void insertWheels();
    void addHeadlights();
    Product getVehicle();
}

class Car implements BuilderInterface {
    private Product product = new Product();

    @Override
    public void buildBody() {
        product.add("This is a body of a car");
    }

    @Override
    public void insertWheels() {
        product.add("4 wheels are added");
    }

    @Override
    public void addHeadlights() {
        product.add("2 headlights are added");
    }

    @Override
    public Product getVehicle() {
        return product;
    }
}

class MotorCycle implements BuilderInterface
{
    private Product product = new Product();

    @Override
    public void buildBody() {
        product.add("This is a body of a Motorcycle");
    }

    @Override
    public void insertWheels() {
        product.add("2 wheels are added");
    }

    @Override
    public void addHeadlights()  {
        product.add("1 Headlight has been added");
    }

    @Override
    public Product getVehicle() {
        return product;
    }
}

Advantage:

It provides clear separation between the construction and representation of an object.
It provides better control over construction process.
It supports to change the internal representation of objects.
Single responsibility principle.

DisAdvantages

Complexity of code increases.

Github Link:
Builder Design Pattern Github repo

Factory Design Pattern

Amrinder singh — Wed, 31 Jul 2019 10:07:48 +0000

What is it?
Factory Method is a creational design pattern that defines an interface or abstract class for creating an object, but allows subclasses to decide the type of objects that will be instantiated.

Problem
Let's say you own a Cab service company and provide cars as a mode of transport to travelers. Soon your service becomes famous and you want to expand your service to provide other modes of transportation say bikes. To do so you have to change your entire codebase to support bikes.

Solution
The Factory Method pattern suggests that instead of creating objects directly (using new operator) we use a factory method that creates an object for us. In our case instead of creating a new car object we let a factory method create an object for us and return the object we want car/bike

Class Diagram:

Example:

class Factory {
    public static void main(String[] args) {

        Transport t1 = CabService.getInstance().getCab("CAR");
        System.out.println(t1.getRate());

        Transport t2 = CabService.getInstance().getCab("BIKE");
        System.out.println(t2.getRate());

    }
}

class CabService{
    private static CabService onlyInstance;

    // Make the constructor private so its only accessible to
    // members of the class.
    private CabService() {
    }


    // Create a static method for object creation
    synchronized public static CabService getInstance() {

        if (onlyInstance == null) {
            // Only instantiate the object when needed.
            synchronized (CabService.class) {
                if (onlyInstance == null) {
                    onlyInstance = new CabService();
                }
            }
        }
        return onlyInstance;
    }

    public Transport getCab(String type) {
        return new CabFactory().getTransport(type);
    }
}

class CabFactory {

    //Factory method that returns transport based on type requested
    public Transport getTransport(String type) {
        switch(type) {
            case "CAR" :
                return new Car();
            case "BIKE" :
                return new Bike();
            default:
                return null;
        }
    }
}

//Transport abstract class
abstract class Transport {
    double rate = 0;
    public double getRate() {
        return rate;
    }
}

class Car extends Transport {
    double rate = 10;
    public double getRate() {
        return rate;
    }
}

class Bike extends Transport  {
    double rate = 5;
    public double getRate() {
        return rate;
    }
}

Usages:

When a class doesn't know what sub-classes will be required to create.
When a class wants that its sub-classes specify the objects to be created.
When the parent classes choose the creation of objects to its sub-classes.
when you want to provide users of your library or framework with a way to extend its internal components.
when you want to save system resources by reusing existing objects instead of rebuilding them each time

Advantages:

Factory Method Pattern allows the sub-classes to choose the type of objects to create
It promotes the loose-coupling by eliminating the need to bind application-specific classes into the code
Single Responsibility Principle
Open/Closed Principle

DisAdvantages:

The code may become more complicated since you need to introduce a lot of new subclasses to implement the pattern.

Github repo Link:
Factory Design Pattern Github

Singleton Design Pattern

Amrinder singh — Sat, 27 Jul 2019 18:21:01 +0000

Real-World Analogy
Sun of our solar system is an excellent example of the singleton pattern. All the planets in our solar system have one sun and it has a global point of acess.

What is it?
Singleton is a creational design pattern that lets you ensure that a class has
only one instance and the instance has a global access point

The singleton design pattern solves problems like:

How can it be ensured that a class has only one instance?
How can the sole instance of a class be accessed easily?
How can a class control its instantiation?
How can the number of instances of a class be restricted?

Solution:
All implementations of the Singleton have these steps in common:

Make default constructor private to control class instantiation
Create a static creation method that underhood the hood uses the private constructor to create an instance then stores it in a static field and all subsequent calls to this method return cached object

Class Diagram:

Example:

The above code will work for single threaded applications . But there's a potential that multiple objects get created in a multithreading environment. Here's one example scenario:

Thread A calls the method getInstance and finds the onlyInstance to be null but before it can actually new-up the instance it gets context switched out.
Now thread B comes along and calls the getInstance method and goes on to new-up the instance and returns the Sun object.
When thread A is scheduled again, is when the mischief begins. The thread was already past the if null condition check and will proceed to new-up another object of Sun and assign it to onlyInstance. Now there are two different Sun objects out in the wild, one with thread A and one with thread B

There are two trivial ways to fix this race condition:

One is to add synchronized to the getInstance() method.
- synchronized public static AirforceOne getInstance()
The other is to undertake static initialization of the instance, which is guaranteed to be thread-safe.
- private static AirforceOne onlyInstance = new AirforceOne();

Pusedo Code:

Advatntages:

A class has only a single instance.
You gain a global access point to that instance.
The singleton object is initialized only first time.

DisAdvantages

Violates the Single Responsibility Principle.
The pattern requires special treatment in a multithreaded environment so that multiple threads won’t create a singleton object several times.
Difficult to unit test

Github Code Repository:
The code for the Singleton pattern can be found at following github repository:
Github repository link: Singleton pattern