Let’s verify that all that code works well together. Once again, build the application and run the service. Use curl or any tool of your choice to exercise the application. Here’s a series of curl calls to exercise the service.
| $ curl -w " " -X GET http://localhost:8080/task |
| $ echo "" |
| $ curl -w " " -X POST |
| -H "Content-Type: application/json" |
| -d '{"description": "write code"}' http://localhost:8080/task |
| $ curl -w " " -X POST |
| -H "Content-Type: application/json" |
| -d '{"description": "test"}' http://localhost:8080/task |
| $ echo "" |
| $ curl -w " " -X GET http://localhost:8080/task |
| $ echo "" |
| $ curl -w " " -X DELETE http://localhost:8080/task/1 |
| $ curl -w " " -X DELETE http://localhost:8080/task/10 |
| $ echo "" |
| $ curl -w " " -X GET http://localhost:8080/task |
First, we perform a GET operation on the task endpoint. Since we’ve not created any tasks yet, this should return an empty collection. Then we make two calls to add two tasks, with descriptions “write code” and “test,” using the POST method to the same endpoint. We then query to verify the tasks have been added. Finally, we delete two tasks with one valid id and one nonexistent id and query the tasks list again. Here’s the output of all these calls to the web service we wrote:
| [] |
| |
| added task with description write code |
| added task with description test |
| |
| [{"id":1,"description":"write code"},{"id":2,"description":"test"}] |
| |
| Task with id 1 deleted |
| Task with id 10 not found |
| |
| [{"id":2,"description":"test"}] |
The output shows all went well. The Kotlin version of code has twenty-five to forty percent less code compared to the Java version. And the low ceremony and expressive nature of Kotlin shines throughout the code. The more complex operations we have to perform in the services and controllers, the bigger gain we’ll see when using Kotlin compared to using Java.