Geek Apprentice

Java 8 Lamdas

2018-02-15T02:38:00.002-08:00

Java 8 has introduced functional programming.Before java 8 there is nothing we can not not do with java7,but with functional programming we can write better code ,more readable and maintanable code.Lets look at what kind of problems functional programming solves.

In object Oriented programming everything is class and object ,we can not have any code in isolation.Each and every line of code must belong to class.This can be a problem sometime, not always this is problem but there are some situations where we need some block of code to pass as a method argument or we need to return some block of code from method which is not possible with pure object oriented programming.In order to do that we used to pass an object which has that block of code instead of that block of code.

We use inline values in our day to day activities like,
int a = 10;
double pi = 3.14;

In functional programming we are assignning code to a variable like

aBlockOfCode = {
/*
*code goes here
*/
}

Lets see an example of EMI calculator.We have base interface as EMIcalculator and its concrete implementation as HomeLoanEMICalculator.

EMICalculator interface :

public interface EMICalculator {
    
    public double calculateEMI(double principalAmount,int noOfMonths);

}

Concrete HomeLoanEMICalculator class:

public class HomeLoanEMICalculator implements EMICalculator {

    @Override
    public double calculateEMI(double principalAmount, int noOfMonths) {
        return (principalAmount*9*Math.pow(1+9,noOfMonths))/(Math.pow(1+9,noOfMonths)-1);
    }

}

Client Programme:

public class Client {
    
    public double processrequest(EMICalculator emiCalculator,double principalAmount,int noOfMonths){
        return emiCalculator.calculateEMI(principalAmount, noOfMonths);
    }
    
    public static void main(String[] args) {
        Client client = new Client();
        EMICalculator emiCalculator = new HomeLoanEMICalculator();
        client.processrequest(emiCalculator, 500000, 12);
        
    }

}

This is the pure Object oriented Style of writing code.Here we need pass just behaviour of calculateEMI method but for that we have created HomeLoanEmiCalculator object and pass that object to processRequest() method.See below image,

Instead in functional style programming just pass block of code as a argument to processRequest method() like below,i have copied the method signature as it is in blow image. We just need to remove acccess specifier as values do not have access specifiers and remove method name and return type as java compiler is smart enough to identify return type.After doing changes it looks like below,

See instead of passing HomeLoanEMICalculator's object who has calculateEMI() behaviour here i am directly passing passing behaviour.So instead of passing thing which has behaviour pass the behaviour itself is what functional programing does.

Replace Conditional with Polymorphism

2018-02-14T23:14:00.002-08:00

Replace Conditional with Polymorphism:

This technique adheres to the Tell-Don't-Ask principle: instead of asking an object about its state and then performing actions based on this, it is much easier to simply tell the object what it needs to do and let it decide for itself how to do that.
Removes duplicate code. You get rid of many almost identical conditionals.
If you need to add a new execution variant, all you need to do is add a new subclass without touching the existing code (Open/Closed Principle).

Lets see the EMI calculator example with traditional switch case :

package com.dp.refactor;

public class EMICalculatorTraditional {
    
    public double getEMI(String type,double amount,int periodInMonths){
        switch(type){
        case "HomeLoan":
            return (amount*9*Math.pow(1+9,periodInMonths))/(Math.pow(1+9,periodInMonths)-1);
        case "CarLoan":
            return (amount*10*Math.pow(1+10,periodInMonths))/(Math.pow(1+10,periodInMonths)-1);
        }
        return 0;
        
    }
    public static void main(String[] args) {
        EMICalculatorTraditional emiCalculatorTraditional = new EMICalculatorTraditional();
        System.out.println(emiCalculatorTraditional.getEMI("HomeLoan",50000, 12));
    }

Now what if i need to add one more new EMICalculator that is PersonalLoanEMI calculator.So what i need to do is check over all the code and look where do i need to make changes and again need to test whole application to check if anything else is not affected by my code change.And also this breaks open Close principle of Object Oriented Programming,as we are modifying existing classes.So instead of this create base interface for common action and add concrete classes for all brances of the switch case.And in future if you want to add new branch just add new concrete class implementing base interface.So by doing that you do not need to test whole application,you just need to test your added functionality as you have not touched the existing functionality.This is somewhat similar to strategy design pattern.
See the below modified code:

Base Interface:

package com.dp.refactor;

public interface EMICalculator {
    
    public double calculateLoanInterest(double amount,int periodInMonths);

}

Concrete Classes:
1.HomeLoanEMICalculator:

package com.dp.refactor;

public class HomeLoanEMICalculator implements EMICalculator {

    private static final double rate = 9;
    @Override
    public double calculateLoanInterest(double amount, int periodInMonths) {
        return (amount*rate*Math.pow(1+rate,periodInMonths))/(Math.pow(1+rate,periodInMonths)-1);
    }

}

2.CarLoanEMIcalculator:

package com.dp.refactor;

public class CarLoanEMICalculator implements EMICalculator {

    private static final double rate = 10;
    @Override
    public double calculateLoanInterest(double amount, int periodInMonths) {
        return (amount*rate*Math.pow(1+rate,periodInMonths))/(Math.pow(1+rate,periodInMonths)-1);
    }

}

Client :

package com.dp.refactor;

public class Client {
    
    public static void main(String[] args) {
        
        EMICalculator emiCalculator = new HomeLoanEMICalculator();
        System.out.println(emiCalculator.calculateLoanInterest(50000, 12));
    }

}

Now if you want to add new EMICalculator type as PersonalLoanEMIcalculator you just need to add one more concrete PersonalLoanEMICalculator class implementingEMICalculator base interface.
Thats all
Thanks

Java coding standards

2018-02-14T01:52:00.000-08:00

1.Synchronized classes Vector,Hashtable,Stack and StringBuffer should not be used:

Early classes of Java API ,such as Vector,hashtable,StringBuffer were synchronized to make them thread safe.Unfortunately ,synchronization has a big negative impact on performance,even when using these collections from single threaded environment.It is better to use their non synchronized replacements.

ArrayList or LinkedList instead of Vector
Deque instead of stack
HashMap instead of HashTable
StringBuilder instead of StringBuffer

2.Collection.isEmpty should be used to test for emptiness:

Using Collection.size() to test for emptiness works but it has significant performance issue.Instead of Collection.size(),we should go for Collection.isEmpty() as its time complexity is O(1) whereas Collction.size() has complexity of O(n).

3.Empty array or collections should be returned instead of null:

Returning null instead of actual array or collection forces callers of the method to explicitly test for null ,making them more complex and less readable.

So instead of this below code,

public static List<Result> getResults() {
  return null;                             // Noncompliant
}

use this one,

public static List<Result> getResults() {
  return Collections.emptyList();          // Compliant
}

4.Return of boolean expressions should be wrapped into if then else statement:

Instead of below code ,

if(age > 18){
return true;
}else{
return false;
}

Preferable one is,

return (age>18)

5.Method parameters,caught exceptions and foreach variables should not reassigned:

While it is technically correct to assign to parameters from method bodies .it reduces code readability .Instead all parameters should be treated as final.

Instead of below code,

public int add(int a, int b) {
    a = a + b;                      // Noncompliant
    /* additional logic */
    return a;                       // Seems like the parameter is returned as is, what is the point?
  }

Below one is preferable,

 public int add(int a, int b) {
    return a + b;                   // Compliant
  }

Observer Design Pattern

2018-02-13T01:28:00.000-08:00

The observer pattern is a software design pattern in which an object,called the subject maintains a list of its dependents,called observers and notifies them automatically of any state changes,usually by calling one of their methods.Define a one to many dependency between objects so that when one object changes,all its dependents are notified and updated automatically.

Lets take an example where we have social media post and there are multiple subscribers to that post such that if any new user add comments or like the post,all the subscribers should know about this activity.So lets implement the same with observer pattern.Here Post will act like Subject and Users will act like observers so that whenever any comment is added to post or it is liked ,all the users(observers) gets notified.

  package com.dp.observer;

  public interface Observer {
    
    void update(Object object);

  }

package com.dp.observer;

import java.util.ArrayList;
import java.util.List;
/*
 * Observer
 */
public class User implements Observer{
    
    private List<String> notifications = new ArrayList<>();
    private String name;

    @Override
    public void update(Object object) {
        System.out.println("Hey ,"+name+" "+object.toString());
        notifications.add(object.toString());
    }

    public List<String> getNotifications() {
        return notifications;
    }

    public void setNotifications(List<String> notifications) {
        this.notifications = notifications;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
    

}

package com.dp.observer;

import java.util.ArrayList;
import java.util.List;
/*
 * This is the subject
 */
public class Post {
    private String postContents;
    private List<User> subscribers = new ArrayList<>();
    private List<String> comments = new ArrayList<>();
    private int likes;
    
    public String getPostContents() {
        return postContents;
    }
    public void setPostContents(String postContents) {
        this.postContents = postContents;
    }
    public List<User> getSubscribers() {
        return subscribers;
    }
    public void setSubscribers(List<User> subscribers) {
        this.subscribers = subscribers;
    }
    public List<String> getComments() {
        return comments;
    }
    public void setComments(List<String> comments) {
        this.comments = comments;
    }
    public int getLikes() {
        return likes;
    }
    public void setLikes(int likes) {
        this.likes = likes;
    }
    
    public void incrementLike(){
        likes++;
        notifyObservers("Post like is inscremented by 1");
    }
    public void decrementLikes(){
        likes--;
    }
    public void addComment(String comment){
        comments.add(comment);
        notifyObservers("New comment is added for the post as:"+comment);
    }
    public void addSubscriber(User user){
        subscribers.add(user);
    }
    private void notifyObservers(Object object){
        for (Observer observer : subscribers) {
            observer.update(object);
        }
    }

}

package com.dp.observer;

public class Client {
    public static void main(String[] args) {
        
        Post post = new Post();
        post.setPostContents("Going to manali");
        post.setLikes(10);
        
        User user = new User();
        user.setName("Nitin");
        post.addSubscriber(user);
        
        user = new User();
        user.setName("Sagar");
        post.addSubscriber(user);
        
        post.incrementLike();
        post.addComment("Happy journey");
        
        
    }

}

Output:

Hey ,Nitin Post like is inscremented by 1
Hey ,Sagar Post like is inscremented by 1
Hey ,Nitin New comment is added for the post as:Happy journey
Hey ,Sagar New comment is added for the post as:Happy journey

Builder Design Pattern

2018-02-06T22:26:00.000-08:00

Builder pattern is a creational design pattern used to assemble complex object.he intent of the Builder design pattern is to separate the construction of a complex object from its representation. By doing so the same construction process can create different representations.

Lets think we have to create invoice object ,inside invoice we can have invoice date and amount.What isf invoice has purchase order attributes associated with it then we need to add attributes associated with purchase order in invoice class.So for that either we can extend base invoice class to add new parameters for purchase order attributes but this leads to creating more number of subclasses as the new parameters come in future.Another alternative tho this is add parameters in the same class and add new constructor to create the object.Again same thing more number of attributes and combination of those attributes leads to more number of constructors .So solution to this is Builder pattern..

The Builder design pattern describes how to solve such problems:

·Encapsulate creating and assembling the parts of a complex object in separate builder object.

· A class delegates object creation to a builder object instead of creating the objects directly.

A class can delegate object creation process to builder.

package com.dp.builder;

public interface InvoiceBuilder {
    
    Invoice build();

}

package com.dp.builder;

import java.sql.Date;
import java.util.List;

public class Invoice {
    
    
    private String name;
    private double amount;
    private Date purchaseOrderDate;
    private String purchaseOrderNumber;
    private List<String> items;
    
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public double getAmount() {
        return amount;
    }
    public void setAmount(double amount) {
        this.amount = amount;
    }
    public Date getPurchaseOrderDate() {
        return purchaseOrderDate;
    }
    public void setPurchaseOrderDate(Date purchaseOrderDate) {
        this.purchaseOrderDate = purchaseOrderDate;
    }
    public String getPurchaseOrderNumber() {
        return purchaseOrderNumber;
    }
    public void setPurchaseOrderNumber(String purchaseOrderNumber) {
        this.purchaseOrderNumber = purchaseOrderNumber;
    }
    public List<String> getItems() {
        return items;
    }
    public void setItems(List<String> items) {
        this.items = items;
    }
    @Override
    public String toString() {
        return "Invoice [name=" + name + ", amount=" + amount + ", purchaseOrderDate=" + purchaseOrderDate
                + ", purchaseOrderNumber=" + purchaseOrderNumber + ", items=" + items + "]";
    }
    
    
    
    

}

package com.dp.builder;

import java.sql.Date;
import java.util.List;

public class InvoiceBuilderImpl implements InvoiceBuilder{
    
    private String name;
    private double amount;
    private Date purchaseOrderDate;
    private String purchaseOrderNumber;
    private List<String> items;
    
    public InvoiceBuilderImpl invoiceName(String name){
        this.name = name;
        return this;
    }
    
    public InvoiceBuilderImpl invoiceAmount(double amount){
        this.amount = amount;
        return this;
    }
    public InvoiceBuilderImpl purchaseOrderDate(Date purchaseOrderDate){
        this.purchaseOrderDate = purchaseOrderDate;
        return this;
    }
    public InvoiceBuilderImpl invoiceAmount(String purchaseOrderNumber){
        this.purchaseOrderNumber = purchaseOrderNumber;
        return this;
    }
    public InvoiceBuilderImpl invoiceItems(List<String> items){
        this.items = items;
        return this;
    }

    @Override
    public Invoice build() {
            Invoice invoice = new Invoice();
            invoice.setName(name);
            invoice.setAmount(amount);
            invoice.setPurchaseOrderDate(purchaseOrderDate);
            invoice.setPurchaseOrderNumber(purchaseOrderNumber);
            invoice.setItems(items);
            return invoice;
    }
    

}

package com.dp.builder;

import java.sql.Date;
import java.util.Arrays;

public class Client {
    
    public static void main(String[] args) {
        
        //create purchase order invoice 
        Invoice poInvoice = new InvoiceBuilderImpl().invoiceName("poInvocie").invoiceAmount(5000).invoiceItems(Arrays.asList("product1","product2")).purchaseOrderDate(new Date(12, 12, 12)).build();
        
        //create non purchase order invoice
        Invoice nonPoInvoice = new InvoiceBuilderImpl().invoiceName("nonPoInvoce").invoiceAmount(10000).build();
    
    }

}

Object Pool Design Pattern

2018-02-04T22:31:00.003-08:00

Object pool is a software creational design pattern which keeps pool of objects and returns object from there only.

When it is necessary to work with a large number of objects that are particularly expensive to instantiate and each object is only needed for a short period of time, the performance of an entire application may be adversely affected. An object pool design pattern may be deemed desirable in cases such as these.Object pooling can offer a significant performance boost in situations where the cost of initializing a class instance is high and the rate of instantiation and destruction of a class is high – in this case objects can frequently be reused, and each reuse saves a significant amount of time.The object pool design pattern creates a set of objects that may be reused.

Object pool can solves object creation problems in two ways.

In first way,whenever an object is requested ,if object is available then it is returned and if object is not available new object is created.

In second way,whenever an object is requested,it is checked if an object is available,if available then object is returned if not exception may be thrown or application needs to wait for object to get free.In first case pool size is not fixed,and in second case pool size is fixed and it can behave like singleton as we are creating fixed no of objects and we will be using only those throughout the application.

Following is the code for case one:

Abstract Object Pool:

package com.dp.objectpool;

import java.util.Enumeration;
import java.util.concurrent.ConcurrentHashMap;

public abstract class ObjectPoolAbstract<T> {
    
    private int exipreTime;
    private ConcurrentHashMap<T,Long> locked,available;
    
    public ObjectPoolAbstract() {
        //object that is created will be available for 40 seconds after that it will be not used any more.
        exipreTime = 4000;
        locked = new ConcurrentHashMap<>();
        available = new ConcurrentHashMap<>();
    }

    //these methods are specific to concrete implementation and hence are kept as abstract
    protected abstract T create();
    public abstract boolean validate(T t);
    public abstract void expire(T t);
    
    public synchronized void checkIn(T t){
        locked.remove(t);
        available.put(t, System.currentTimeMillis());
    }
    
    public synchronized T checkOut(){
         T t = null;
        if(available.size() > 0){
             Enumeration<T> e = available.keys();
              while (e.hasMoreElements()) {
                  t = e.nextElement();
                    if ((System.currentTimeMillis() - available.get(t)) > exipreTime) {
                      // object has expired and will be removed from available map also because expire time has reach
                        //objects will remain in available map till expire time is not reached from last reference to the that objects
                      available.remove(t);
                      expire(t);
                      t = null;
                    } else {
                      if (validate(t)) {
                        available.remove(t);
                        locked.put(t, System.currentTimeMillis());
                        return (t);
                      } 
                      else {
                          // object failed validation
                          available.remove(t);
                          expire(t);
                          t = null;
                        }
                    }
            
              }
        }   
            t = create();
            locked.put(t, System.currentTimeMillis());
            return t;
    }
}

2.Concrete Implmentation of ObjectPool:

package com.dp.objectpool;

import java.io.IOException;
import java.net.Socket;

public class SocketPoolConcrete extends ObjectPoolAbstract<Socket>{
    
    private String server;
    private int portNo;
    public SocketPoolConcrete(String server,int portNo) {
        this.server = server;
        this.portNo = portNo;
    }
    @Override
    protected Socket create() {
        Socket socket = null;
        try {
            socket = new Socket(server,portNo);
        } catch (IOException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        } 
        return socket;
    }
    @Override
    public boolean validate(Socket t) {
        return !((Socket)t).isClosed();
    }
    @Override
    public void expire(Socket t) {
        try {
            ((Socket)t).close();
        } catch (IOException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        
    }

}

3. Client

package com.dp.objectpool;

import java.net.Socket;

public class Client {

    public static void main(String[] args) {
        //get client socket object to communicate with server at localhost:8080(to run this server socket must listens at localhost:8080)
        SocketPoolConcrete socketPool = new SocketPoolConcrete("Localhost",8080);
        Socket socket = socketPool.checkOut();
    
        /*.
         * 
         * do your task
        .*/
        
        socketPool.checkIn(socket);
    }
}

Factory Design Pattern

2018-02-01T23:07:00.002-08:00

Factory design pattern is one of the creational design pattern for creating objects with respect to Object Oriented systems.What is the most usual method of creating object,most people think that using new keyword.But creating object with new keyword makes components tightly coupled,if we need to change object creation process then we need to change it in all places in our programme. So in order to make components loosely coupled Factory pattern is one solution.Loose coupling is achieved in Factory pattern by implenting at interfaces and not at concrete classes.

The intent of factory pattern is:

1.Creates the object without exposing object creation logic to client
2.refers to newly created object through common interface(through factory)

Lets take look at example where we need various DB connectors like MsSQLConnector,OracleConnector and SQLServerConnector,we can use factory design pattern.

1.Connector Type enum:

package com.dp.factory;

public enum ConnectorType {
    MsSQlConnector, OracleConnector, SQLserverConnector
}

2.Connector interface:

package com.dp.factory;

public interface Connector {
    
    public void connect();

}

3.Concrete MsSQLConnector class:

package com.dp.factory;

public class MsSQLConnector implements Connector {
    
    public MsSQLConnector() {
        connect();
    }

    @Override
    public void connect() {
        System.out.println("Connecting to MsSQLDatabase.!!!!!!!!");

    }

}

3.Concrete OracleConnector class:

package com.dp.factory;

public class OracleConector implements Connector {
    
    public OracleConector() {
        connect();
    }

    @Override
    public void connect() {
        System.out.println("Connecting to oracle database.!!!!!!!!!");

    }

}

3.Concrete SQLServerConnector class:

package com.dp.factory;

public class SQLServerConnector implements Connector {
    
    public SQLServerConnector() {
        connect();
    }

    @Override
    public void connect() {
        System.out.println("Connecting to SQLConnector database.!!");
        
    }

}

4.Factory class to get connector type:

package com.dp.factory;

public class DBConnectorFactory {
    
    public static Connector getDBConnector(ConnectorType type){
        Connector connector = null;
        switch(type){
        case MsSQlConnector :
            connector = new MsSQLConnector();
            break;
        case OracleConnector :
            connector = new OracleConector();
            break;
        case SQLserverConnector : 
            connector = new SQLServerConnector();
            break;
        }
        return connector;
    }

}

5.Client:

package com.dp.factory;

public class Client {
    
    public static void main(String[] args) {
        Connector connector = null;
        connector = DBConnectorFactory.getDBConnector(ConnectorType.MsSQlConnector);
        System.out.println(connector.getClass().getName());
        connector  =DBConnectorFactory.getDBConnector(ConnectorType.OracleConnector);
        System.out.println(connector.getClass().getName());
        connector = DBConnectorFactory.getDBConnector(ConnectorType.SQLserverConnector);
        System.out.println(connector.getClass().getName());
    }

}

This is the simple and intutive implmentaion for factory pattern.What if we need to add one more concrete DBConnector as DB2Connector?...we need to modify factory class to add one more switch case for DB2Connector type of objects.But this is against Open Close principle of Object oriented programming.

Need to change Factory and client and Concrete classes as well:
So the code looks like:

package com.dp.factory;

public enum ConnectorType {
    MsSQlConnector, OracleConnector, SQLserverConnector
}


package com.dp.factory;

public interface Connector {
    
    public void connect();

}


package com.dp.factory;

public class MsSQLConnector implements Connector {
    
    
    static{
        DBConnectorFactory.getInstacne().addConnector(ConnectorType.MsSQlConnector,  MsSQLConnector.class);
    }
    
    public MsSQLConnector() {
        connect();
    }

    @Override
    public void connect() {
        System.out.println("Connecting to MsSQLDatabase.!!!!!!!!");

    }

}


package com.dp.factory;

public class OracleConector implements Connector {
    
    static{
        DBConnectorFactory.getInstacne().addConnector(ConnectorType.OracleConnector,  MsSQLConnector.class);
    }
    
    public OracleConector() {
        connect();
    }

    @Override
    public void connect() {
        System.out.println("Connecting to oracle databse.!!!!!!!!!");

    }

}




package com.dp.factory;

public class SQLServerConnector implements Connector {
    
    static{
        DBConnectorFactory.getInstacne().addConnector(ConnectorType.SQLserverConnector,  MsSQLConnector.class);
    }
    
    public SQLServerConnector() {
        connect();
    }

    @Override
    public void connect() {
        System.out.println("Connecting to SQLConnector database.!!");
        
    }

}


package com.dp.factory;

import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
import java.util.HashMap;
import java.util.Map;

public class DBConnectorFactory {
    static DBConnectorFactory factory = null;
    private DBConnectorFactory(){
        
    }
    private Map registeredConnectors = new HashMap<>();
    
    public void addConnector(ConnectorType connectorType,Class connectortypeClass){
        registeredConnectors.put(connectorType, connectortypeClass);
    }
    
    public Connector getDBConnectorFromMap(ConnectorType type) throws NoSuchMethodException, SecurityException, InstantiationException, IllegalAccessException, IllegalArgumentException, InvocationTargetException{
        Class connectorClass = (Class)registeredConnectors.get(type);
        Constructor[] connectorConstructor = connectorClass.getConstructors();
        return (Connector)connectorConstructor[0].newInstance(new Object[] { });
    }
    
    public static DBConnectorFactory getInstacne(){
        
        if(factory == null){
            factory = new DBConnectorFactory();
            return factory;
        }
        else{
            return factory;
        }
    }

}


package com.dp.factory;

import java.lang.reflect.InvocationTargetException;

public class Client {
    
    
    static{
        try
        {
            Class.forName("com.dp.factory.MsSQLConnector");
            Class.forName("com.dp.factory.OracleConector");
            Class.forName("com.dp.factory.SQLServerConnector");
        }
        catch (ClassNotFoundException any)
        {
            any.printStackTrace();
        }
    }
    public static void main(String[] args) throws NoSuchMethodException, SecurityException, InstantiationException, IllegalAccessException, IllegalArgumentException, InvocationTargetException {
        
        
        Connector connector = DBConnectorFactory.getInstacne().getDBConnectorFromMap(ConnectorType.MsSQlConnector);
    }

}

RESTful API Designing guidelines — The best practices

2018-02-01T02:02:00.002-08:00

What are RESTful web services:

REST is an architectural style which provides direction for building distributed ans loosely coupled systems.REST is not linked to any particular platform or its an idea to develop services to function similar to the web.

REST is nothing but REpresentational State Transfer.It describes how one system can communicate with another over web.We can compare REST services as methods in our programme,in order achieve certain tasks in our programme we are calling some methods from our programme,in the same way we are creating REST web services.I would rather say REST web services and methods on web that can be consumed by calle(clients like browser,mobile apps or other consumers.).So two systems can comminucate over web with the help REST web services so there must by some data that will be exchanged between two parties.That data should be having some state at particular instance and has some form of representaion,so this is nothing but REpresentation state transfer.For example,we have an emplopyee object having id,name and address as attributes.So curently that object has id=1,name='xyz' and address='India' as current state and we pass it as JSON.So this is what as REpresentaional state transfer.

Most people think that REST is HTTP but REST is not HTTP because in its most general form REST exists to assist the concept of verb against an arbitary collection of nouns.

One most important point is what is the difference between website and a web service.A website is consumed by humans whereas web services are consumed by programmed clients.

REST web services rests on three mail things and those are Resources,Representation and Verbs.URL in web services is a sentence where resources are nouns and verbs are HTTP methods.

Resources:Resources are the endpoints of API.They may be business entities like student,employee and so on.While working on rest web services ,the first task is to identify resources and how they link with each other.

Representation: Representation is nothing but a way to showcase resources to clients.REST supports most of the representation formats including but not limited to json,xml.

Verbs:Verbs decides what actions to perform an given resource.Verbs can be GET,PUT,POST and DELETE etc.

Guidelines for designing REST web services:

1)API Endpoint:

Lets say we have resource as employee and we need to write REST API's for that,so we can start as:

employee/createEmploye
employee/deleteEmployee
employee/updateEmployee
employee/createEmployee

This will results in tons of API's and it can duplicate the code and increases maintance cost associated with the API's.So what's wrong with the above way to create API's.URL should only contain resources and not verbs,let the HTTP Verbs do the job and do not include those verbs in URL.

So the API endpoints should look like,

URL : employee/ HTTP verb:POST will create employee resource
URL: employee/{id} HTTP verb:GET will get employee specified by id
URL: employee/{id} HTTP verb:DELETE will delete employee specified by id
URL:employee/{id} HTTP verb:PUT will update employee specified by id

Now lets say we have resources under resource like we have employee under department we can have,

URL : department/{id}/employee HTTP verb:POST create employee under department specified by id
URL: department/{deptId}/employee/ HTTP verb:GET get all employee under department specified by deptId
URL: department/{deptId}/employee/{empId} HTTP verb:GET get employee with id empId under department specified by deptId
URL: department/{deptId}/employee/{empId} HTTP DELETE delete employee with id empId under department specified by deptId

2)HTTP methods:

1.GET : retrieve an existing resource.
2.POST : Create new entry for resource.POST is non idempotent method which means every time a request is made it has different effect.
3.PUT : Modify an existing resource.PUT is idempotent method which means every time request is made it has same effect.
4.DELETE : Delete an existing resource.

3)HTTP response codes:

Whenever a request is made to server it must return some response either failed or success,so that client can aware of it.For successful operation it should return 2xx series status codes.For client request error 4xx series status codes and for server side error 5xx status codes should be return

4)Versioning:

Versioning should be considered when the servers are unable to maintain the compatibility.Versioning is done if some clients wants different behaviuor than others.Versioning can be accomplish using version number in URL or it can be achieved using accept and content type with version numbers instead of specifying in the URL.
Lets say we have Order as resource and we need to create two versions of this resource where in one API order resource should not include items within it which is V1 and other API which includes items within the order then we can have,

Example of version number in URL:

v1/order/{id} HTTP verb:GET get order specified by id(does not include items in order)
v2/order/{id} HTTP verb:GET get order specified by id(include items in order)

Example of version number in header:

order/{id} Accept:application/json;version=1 get order specified by id(does not include items in order)
order/{id} Accept:application/json;version=2 get order specified by id(include items in order)

These are my own opinions on designing RESTful web services,your views are also welcome.

Rest Assured

2018-01-25T05:01:00.002-08:00

REST ASSURED : Testing API endpoints

With the increase popularity of RESTful services, there is a need for fast and lightweight tool for REST webservices testing automation. One of the most popular choice is Rest-Assured framework from Jayway. It introduces simplicity of testing web services from dynamic languages like groovy or ruby to java. REST-assured provides a lot of nice features,such as DSL-like syntax, XPath-Validation, Specification Reuse, easy file uploads and with those features we will handle automated API testing much easier.the preferred and current way is to use the newer BDD (Behavior Driven Development) like given-when-then syntax.When you create BDD features, the majority of its scenarios will be made up of three main Gherkin keywords: Given, When and Then. Each one has a particular function:

Given = a context/Getting a system in a particular state

When = something happens/Poke it

Then =we expect some outcome/examine the new state

Why REST-assured?

Let’s look at what is expected from a tool that helps in writing automated tests for REST APIs and how REST-assured lives upto these expectations.

Easy HTTP Request Building and Execution : Requesting building comprises of defining many things like query params, cookies, headers, path params and request body. Using it’s DSL, REST-assured hides away the complexity of building and executing an HTTP request behind a fluent interface. We will see this in action in the next section.

Response Assertions : REST-assured also handles, within its library, the parsing of responses. It provides many constructs for making assertions on cookies, response headers and response body. For doing assertions on response body it provides JsonPath for assertions on JSON responses and XmlPath for assertions on XML responses. It also also uses Java Hamcrest Matchers to make readable assertions.

Ability to write Clean Code : The real value of automated tests is realized when they are easy to understand and takes very less effort to maintain them. In the dictionary of REST-assured’s DSL, you can also find constructs for writing in
Given-When-Then style. Using this style helps in specifying pre-conditions under the Given section, behavior under test under the When section and verifications under the Then section. This helps in maintaining a clear separation of concerns within a test, thus leading to a very readable test.

Lets’ take a look at examples:

1.I want to get list of all countries.The example is as:

RequestSpecification request=new RequestSpecBuilder().build();
ResponseSpecification response=new ResponseSpecBuilder().build();

@Test(enabled=true)
public void getAllCountries()
{
given()
.spec(request)
.get(API_ENDPOINT_FOR_GETTING_ALL_CONTRIES)
.then()
.statusCode(200);
}

Here we are making get request to API_ENDPOINT and checking for statuscode 200.

Now lets see how to pass queryparams in get request.Suppose i want to pass ContryCode and get all cities.The request looks like:

@Test(enabled=true)
public void getAllCities()
{
given()
.spec(request)
.queryParam(“countryId”, “AR”)
.get(API_ENDPOINT_FOR_GETTING_CITIES_BY_COUNTYID)
.then()
.statusCode(200);
}

TDD (Test Driven Devlopment)

2018-01-25T04:40:00.001-08:00

TDD-Test Driven Development

Dark secret behind TDD is - TDD has nothing to do with testing its all about requirements and design driven development.

TDD is an approach for software development where developers write unit tests before start working on actual implementation.Here our tests represents the requirements that we will be implementing.So unit tests in TDD drives the design and development of code.

Whenever new feature is to be developed,unit tests are written first.At first all tests must fail because the implementation for those tests is not there.If your tests are pass then the functionality you will be developing is already present there so no need to duplicate the code.Once your tests fails then you start developing the code which will pass those tests.This will result in avoiding writing unecesary code which is not required.Once all the tests are passed you can refactor the code to make it upto the standards.

The simple concept of TDD is to write and correct the failed tests before writing new code (before development). This helps to avoid duplication of code as we write a small amount of code at a time in order to pass tests.

Before TDD people follows the traditional approach as People read the requirements or get requirements from stake holders or product owner and come up with some details and then come up with architecture design, code analysis , db design, etc.. and then later start writing the code and write tests around the newly developed functionality.once this is tested, they would unearth bugs and bugs would be logged for the same, so here there is back and forth between developer and tester.

Which increases the cycle of development and releasing the product or release

In TDD people will start writing test cases, which would obviously fail at the first hand as there is no code or functionality written so far to satisfy the test.

Now, team would start writing code to pass the test and indirectly address the functionality to make sure the tests pass, in this way basically the code is more qualitative and the number of to and fros would be minimized.

The steps in TDD are:

1. Write a test that tests a specific part of the user story or feature you're developing.

2. Run the test. It should fail right now, because you haven't written any code yet. If your test doesn't fail your existing code already behaves correctly or more likely your test doesn't test anything.

3. Make the simplest possible change to your code that ensures the test succeeds. It's important that you do not make changes that go beyond your test, even if you know that you're going to change that later. This ensures that you do not introduce behavior that is untested because in TDD your tests are a major part of your documentation. It is also important that you do not touch anything that is unrelated to the test your trying to satisfy.

4. Run your test again. It should now succeed. But if it fails go back to 1. Make sure that your test is actually correct before you try to find the problem in your code.

5. When your test is satisfied refactor your code. Since in step 3 you did not touch anything unrelated to the test you may have introduced code smells. But because all of your existing code is now fully covered by tests (one of the reasons why TDD would be used in the first place) you can now safely reorganize it, and as long as your tests still succeed you're doing it right.

There are three stages in TDD drive approAch for modern software development.First one is RED stage,GREEN Stage and third one is refactor.

In RED stage,developers write tests for missing behaviour and when executed those tests will fail because desired implementation is not implemented yet.

In Green stage,minimal code that makes the failing tests to pass is written and no extra code is written.

In Reactoring,as in GREEN stage we have written minimal code to pass ths the failing tests,here in this stage code refactoring is done to make code to the coding standards and remove any other code smells.

Test driven development is a micro cycle that needs to follow throughout the development. Ideally the code written with TDD approach should have:

1.All the test pass

2.It has no duplication

3.It communicates its intent

4.No unwanted parts exist

One of the chief limitations of TDD is the fact that tests can sometimes be incorrectly conceived or applied. This may result in units that do not perform as expected in the real world. Even if all the units work perfectly in isolation in all anticipated scenarios, end users may encounter situations not imagined by the developers and testers.

The final results of TDD are only as good as the tests that have been used, the thoroughness with which they have been done and the extent to which they mimic conditions encountered by users of the final product.