All New HTTP QUERY Method - RFC-10008

For a very long time, whenever I needed to send a query to a server, I had only two real options: GET or POST. Both worked. Based on personal preference, some prefer to use the HTTP GET method and others prefer HTTP POST. Recently, while going through the newly published RFC 10008, I came across a new HTTP method called QUERY that finally fills this gap. In this post, I am going to walk through what it is, why we need it, and how it actually works.

The problem with GET and POST

The most common way to send a query is to encode everything into the URL query parameters and send a GET request.

GET /feed?q=foo&limit=10&sort=-published HTTP/1.1

Host: example.org

This is clean and works well for most use cases, until your system grows.

1. URLs have practical size limits. HTTP itself doesn't define a maximum URI length, but every system our request goes through has its own limits. Browsers, servers, proxies, load balancers, and CDNs all impose their own limits. Based on the RFC, it's said to be 8 KB. If any of these underlying systems has a URI limit, our request can be rejected with 414 URI Too Long.
2. Encoding. When working with nested filters, arrays, JSON, or query parameters with spaces, quotes, or Unicode, it is more prone to data-handling issues and even a nightmare to debug and isolate a real production issue.
3. Sensitive data exposure. URIs are far more likely to be logged in browser history or saved in bookmarks than the request body, so putting sensitive data there is risky.
4. Caching issues. For a GET request, the cache uses the full URL as the label for each stored response. The cache only reuses a stored response if the URL matches exactly; it doesn't understand if the user sends the same query parameters in a different order. Because of this, there will be fewer cache hits and wasted cache storage.

Kafka - A Quick and Simple Guide

Introduction

Apache Kafka is a distributed event streaming platform. Originally developed at LinkedIn, it is now an open-source project under the Apache Software Foundation. Kafka is widely used for building real-time data pipelines and streaming applications.

What is Apache Kafka?

Kafka is a messaging system that lets applications publish (write), subscribe (read), store, and process streams of data in real-time.

Kafka Core Concepts

1. Producers and Consumers

•     Producers → Send data to Kafka topics.
•     Consumers → Read data from Kafka topics.

2. Topics and Partitions

• Topic → Logical channel for a specific type of data.
• Partition → Topics are split into partitions for scalability. Each partition stores data in order.

3. Brokers and Cluster

• Broker → Kafka server that stores data.
• Cluster → Group of brokers working together.

4. Zookeeper

    Kafka uses Zookeeper to manage broker metadata and coordination tasks.

    Note: Newer Kafka versions can run without Zookeeper (KRaft mode).

5. Replication Factor
   This provides fault tolerance and state how many copies of each partition exist across brokers. as example if replication factor is 3, that mean partition will kept inside leader and 2 brokers

6. Partition Rebalancing

     When consumer join or leave a consumer group, Kafka will triggers a rebalance to redistribute partitions among the available consumers. This will ensure load balancing, but it may temporarily stop message processing

XSLT Date and Time Manipulation

In XSLT (Extensible Stylesheet Language Transformations) 2.0 or later, we can perform several date and time manipulation processes. I thought of writing a blog post so others can easily find examples as well.

Basic Date & Time XSLT Functions: 

current-date() - Returns the current date of the server that XSLT runs

current-time() - Returns the current time of the server that XSLT runs

current-dateTime() - Returns the current date and time of the server that XSLT runs

implicit-timezone() - Returns the implicit time zone of the server that XSLT runs

Global Exception Handling With Spring Boot

In a Spring Boot controller, things can sometimes go wrong. For example, an API consumer might not send the expected path parameter or header value. They might call the API with an invalid payload or encounter an unexpected runtime error. When these kinds of errors occur, we can use Spring Boot's Global Exception Handling mechanism to manage them and provide meaningful responses back to the API consumer.

@ExceptionHandler is used to handle exceptions in specific controllers classes and/or methods level. In a Spring Boot Restful service, errors can be handled in three different ways:

1. Using ControllerAdvice - This annotation allows global(central) exception handling across multiple controllers.
2. Using @ExceptionHandler at each controller level - For more granular control
3. Returning ResponseEntity with the appropriate status code

In this post, I will explain how to implement Global Exception Handling in a Spring Boot RESTful service.