As mentioned previously, there are also thin clients, which don't include a lot of code to interact with the server; one good example of a thin RESTful web service client is curl.

In order to interact with the endpoints provided by the server example, we can use two curl commands, as follows:

• The following code provides for retrieving the authentication JWT token:

$ curl -H "Content-Type: application/json" 
-X POST -d '{"username":"rene","password":"rene"}' 
http://localhost:8080/api/public/auth

• The following code provides for using the JWT token to query the user's account balance:

$ curl -H "x-auth-token: JWT_TOKEN" 
-X GET http://localhost:8080/api/secure/balance

For these kinds of clients, we don't have to write our own code; the interaction with the server doesn't have a fancy frontend, which can be good (in cases where the API is used for other middleware, for example).

As you can see, our client-server architecture implementation is simple, but it uses all of the necessary pieces to make it work. In this case, we have used the HTTP protocol as the communication channel. However, depending on what kind of server you are implementing, it may be different, and it can also affect the authentication mechanism. For example, when you're using a message broker such as RabbitMQ to allow for the interaction between servers and clients, the protocol to establish the communication is AMQP, which is a different protocol (in comparison to HTTP). 

The kinds of clients that your application will have also affects the way in which you will build the solution. Let's suppose that you're using agents as clients; a more secure authentication mechanism would be based on the use of certificates instead of tokens, as seen in the preceding example.