Since our server is implemented using RESTful web services, there are a bunch of options for writing clients and consuming them with libraries, such as Netflix Feign, OkHttp, Spring Rest Template, and Retrofit.

Because of this, the clients can have their own implemented mechanisms to consume the services. This approach is not bad at all; actually, we should keep it open, and the decision of writing our own tool to interact with the server should be a client choice, in order to avoid the conformist relationship described earlier. However, it's always a good idea to provide a built-in SDK or library to interact with the server and reduce the amount of effort required for it, and that's the reason we have the banking-client module.

It's quite common to find SDKs provided by product vendors. For example, AWS provides SDKs with support for a bunch of programming languages, in conjunction with a developer guide document that explains how to use them. This is helpful for accelerating and encouraging the adoption of products to build applications by other developers. Another example is Google Firebase, which is a real-time database that provides SDKs that are ready to use in different platforms; it has a website with excellent demos that make it possible for developers to understand how it works and how to use it.
This banking-client module is implemented using a library named Retrofit (http://square.github.io/retrofit/), which makes it possible to write type-safe HTTP clients that can be used for almost any kind of Java application. This also offers many benefits, such as the following:

• Support for mobile apps, like Android
• Code that is easy to read and explains itself well
• Support for synchronous and asynchronous resource consumption
• Smooth integration with converters, such as GSON

Let's take a look at the implemented clients, in order to consume the endpoints.