REST Services: HTTP Status Codes

HTTP defines forty standard status codes that can be used to convey the results of a client’s request. The status codes are divided into the five categories presented below.

CATEGORY                                                   DESCRIPTION

1xx: Informational           Communicates transfer protocol-level information.

2xx: Success                  Indicates that the client’s request was accepted successfully.

3xx: Redirection              Indicates that the client must take some additional action in order to complete their request.

4xx: Client Error             This category of error status codes points the finger at clients.

5xx: Server Error            The server takes responsibility for these error status codes.

200	OK
201	Created
204	No content
301	Moved Permanently
302	Found
303	See Other
304	Not Modified
307	Temporary redirect
400	Bad Request
401	Unauthorized
403	Forbidden
404	Not Found
405	Method not allowed
406	Not acceptable
412	Precondition Failed
415	Unsupported Media Type
500	Internal Server Error
501	Not Implemented
503	Service Unavailable
504	Gateway timeout

Reactive Programming: Blocking(Sync) vs Non-Blocking(Async) Request Processing

Blocking Request Processing:

Most of the time, when we expose any endpoint to external world, internally it follows below flow:

controller <-> service <-> dao <-> DB

The existing servlet frameworks, assign a separate thread to each request and that thread will be blocked for that user, until response is sent or process is erred out. Its a synchronized processing of each request.





Non - Blocking Request Processing:

This is the new style of programming, where the flow of processing would be same as below, however with each request we have event handlers and call back functions.

                                    controller <-> service <-> dao <-> DB

When any request comes, new generation of web containers ( like netty, undertow, Servlet 3.1+) will start assigning threads to each request, however as any request wait for any slow process to finish, that request will be moved to some kind of queue via handlers and that thread will be freed up for new requests, when slow process will finish for that request, callback will be initiated with received data. Here basically requests are asynchronous in nature and threads are not blocked.



image courtesy: https://howtodoinjava.com/spring-webflux/spring-webflux-tutorial/

Spring 5: WebClient vs RestTemplate

In today's micro-services world, where almost everything is exposed as REST endpoints, we are bound to call these REST services.

How do we call ?

We have a convenient class called RestTemplate, provided by Spring. However this is synchronous in nature, it uses Thread-per-Request method. Until each request is completed and response is sent back to user or service erred out, the thread will be blocked out for that user.

Just assume this for heavy traffic but slow response application, within seconds the app will be sending 404 or 500 as it can't handle the request anymore as well as so many existing requests (threads) will degrade the performance of the application.

@GetMapping("/employees")

public List<Employee> getEmployeesBlocking() {

    log.info("Starting BLOCKING Controller!");

    final String uri = getSlowServiceUri();

    RestTemplate restTemplate = new RestTemplate();

    ResponseEntity<List<Employee>> response = restTemplate.exchange(

      uri, HttpMethod.GET, null,

      new ParameterizedTypeReference<List<Employee>>(){});

    List<Employee> result = response.getBody();

    result.forEach(employee -> log.info(employee.toString()));

    log.info("Exiting BLOCKING Controller!");

    return result;

}

is it worth for thread to be blocked, waiting for response from called endpoint ?

can't we free up the thread and queue the task, which can be picked up when we get the response ?

With RestTemplate answer is no... as it is Synchronous in nature, however Spring 5 has new class called WebClient, which can do the job for us.

WebClient works on the concept of Asynchronous and non blocking strategy. it is part of WebFlux Project which is reactive programming extension provided by Spring.

Basically behind the scene it will treat each request as task and queue them when they are waiting for response. The serving thread will be unblocked to serve other requests and once response received for that task, webclient will activate the task by assigning thread to it and finish rest of the execution as programmed.

@GetMapping(value = "/employees",

            produces = MediaType.TEXT_EVENT_STREAM_VALUE)

public Flux<Employee> getEmployeesNonBlocking() {

    log.info("Starting NON-BLOCKING Controller!");

    Flux<Employee> employeeFlux = WebClient.create()

      .get()

      .uri(getSlowServiceUri())

      .retrieve()

      .bodyToFlux(Employee.class);

    employeeFlux.subscribe(employee -> log.info(employee.toString()));

    log.info("Exiting NON-BLOCKING Controller!");

    return employeeFlux;

}

RestTemplate is getting deprecated and will not be supported in future versions of Spring. We should start using WebClient. It not only supports Asynchronous it also supports Synchronous calls so we call use WebClient as a replacement for RestTemplate.