Transcript
Overview: In this lesson, we are going to cover the second part of our POISED testing strategy which is “Output.
Note:
For maximum benefit, please view the course video for dynamic demonstrations.
The next part of our testing strategy is output. If parameters represent the input for your API then the output could be not only the response itself, but the status code, the logging, or perhaps any kind of monitoring information that you want to send.
Let's look at a couple of different parts of the output of Restful Booker.
Usually, when you send an API, or when you send a request the most common response is going to be “200 OK” in the status field.
Let's look at delete booking.
If we want to delete a booking when we hit send, we get a status of “201 Created,” which is a very odd response to have. If we got a 200 OK, then we could be reasonably sure that our delete happened, or if we got a 204. But, in this case, 201 Created is very unclear. Did we just create something new?
We don't know what happened, so this is an output error by Restful Booker.
Another way to control the output in Restful Booker is through the headers. The default is to have it in a JSON format, this with the curly braces, and the values, the key value pairs:
{
“firstname” : “Jim”,
“Lastname” : “Brown”,
“totalprice” : 111,
“depositpaid” : true,
“bookingdates” : {
“checkin” : “2018-01-01”,
“checkout” : “2019-01-01”
},
“additionalneeds” : “Breakfast”
}
But with our headers we can change this output.
We can change it to XML, which might be better for certain services. Let's change this to Accept application/xml and now when I send it I get a response back in an XML format, which is fine.
<booking>
<firstname>Sally</firstname>
<lastname>Jones</lastname>
<depositpaid>true</depositpaid>
<bookingdates>
<checkin>2017-09-15</checkin>
<checkout>2018-08-15</checkout>
</bookingdates>
<additionalneeds>Breakfast</additionalneeds>
</booking>
This is what we want.
Let's see if working for one of the other APIs, in this case, getting all the bookings. Once again, by default, it does a JSON format with curly braces so we need to we add our accept application/xml. When we do this with the “Get All Bookings,” it's still sending JSON, so we obviously have an issue here where this endpoint is not processing the header correctly.
Tip:
You don’t have to type out the entire entry, you can pick it out of the list.
The final thing I want to look at is the logging output.
As you recall, when we were doing our parameter testing we were able to get some values that were incorrect like if the deposit paid field is an empty string we got a 500 Internal Server Error:
“depositpaid” : “”,
Or, we can change booking dates to be an invalid date and see what happens there.
“bookingdates” : {
“checkin” : “2018--01”,
“checkout” : “2019-01-01”
},
Again, we get a 500 error.
When we look at our logs, all it's saying is 500. We're not getting any extra information here.
This is the sort of output that could potentially be useful to an application developer. If there's an error in the date format, it's useful to let them know “hey, something was wrong with the date format, instead of just 500.
This is the sort of value your API can provide. It's not only providing the right answer, it's being able to give clues to the developer when things aren't quite right. That's just some very basic output checking that you could be doing with APIs.
# Code Resource
Quiz:
Note: Chapter 3 has been divided into multiple sub-chapters. You'll find the Quiz on the last sub-chapter, Chapter 3.6. Read on!
