And you should think of Karate as more like a programing language that is very scriptable and gives you great power as you start getting into more advanced concepts while still keeping it simple, of course. The last thing on BDD that I do want to call out now is that given when then are purely here for cosmetic reasons, they don't really do anything or they don't drive any behavior in the backend and so on. In fact, most teams nowadays that I work with instead of given when then you can put a star or an asterisk symbol, which is good enough. You don't need to worry about whether any line should start with given when then.
Okay, so with that, let me get deep into some of the aspects that make Karate what it is. First, JSON is native to the syntax and you can see, by the way, JSON is one of my favorite things now. I find it one of the most elegant ways to express data, which is great because API is, as you know, involved a lot of JSON being sent as well as received. And one of the things I do need to call out about the way JSON looks like in Karate is that it's lenient.
Okay, So next Karate is something we call a DSL or a domain specific language. And let me explain what that means and why the DSL terminology is used. If I call your attention to the first word on each line, you URL request method status, but you straightaway see that it makes sense from an HTTP or REST standpoint. This is something immediately folks, anyone who has got experience with the rest would connect with straight away. And you see how clean and less noisy a Karate test is. These key words are very carefully designed to be readable.
For example, if you look at a Karate test, you will immediately know what kind of API call is being made, whether to get or post, whether you're making the get and the post, and what are the parameters and data being passed. Matching is what I'm showing you now on the slide. The match keyword in Karate is where we do assertions. You can see on this line in a single line of code, Karate is capable of comparing to JSON payloads.
Here we have the response that came back from the API request that we made. And while we can validate all the data, for example, we are checking of the name is exactly equal to "Billie". What is happening here that I'm pointing at the #notnull. That's really interesting because in real life APIs tend to come back with a lot of unpredictable data. You have random values, in this case the UUID, a generated identifier. And the great thing about Karate is match or assertions capability is that you can validate all the data elements that came back from a JSON payload or a response, yet at the same time you could ignore or you could work around those troublesome values, which you cannot predict.
So that's something people really like about Karate. And keep in mind that in real life, even though this is a hello world example, you can have a really complicated JSON come back and we will see one example in a moment as we walk through the first example that you can try out. The last point I want to cover on the slide is that Karate is great at chaining together APIs. When you're really doing a functional test of APIs you would be calling multiple APIs in sequence and using what came back from one response into the next request. And you see that happen here on the third last line where we say from the previous response, take the ID value and use it as a path parameter and good Karate test can involve five six sequences of API calls and when you look at the report, you will actually see a very nice story in terms of what APIs were called and what business functionality were these APIs in working.