Response Codes Explained

If you have ever made a REST request or looked in the developer tools section of a browser, you have likely seen the three-digit response code that is returned with an HTTP request.  This week, we'll be talking about the different types of response codes you might receive when doing API testing, and what those codes mean.  

100-level Responses:

A 100-level response indicates that the request should continue.  The most common 100-level type is the simple 100 Continue.  This can be used with large requests; it gives the server the opportunity to stop a large request before too much data is transmitted.  You probably won't see this in your API testing, because the server response will continue and complete behind the scenes and will then return a 200-level response. 

200-level Responses:

A 200-level response indicates that the request was successful.  The most common response is the 200 OK.  This simply means that everything went as expected.  Here are some other common 200-level responses:

201 Created- this indicates that a new resource has been created as the result of the request.  For example, a GET request might create a log entry that shows the date, time, and content of the request.

202 Accepted- this indicates that the request was accepted, but is not complete yet.  An example of where this could be used would be a pending change that needs approval before being added to the database.

204 No Content- this means that the request was processed successfully, and that no data was returned.  This might be used with a PUT request, where the content is changed, but the developer saw no need to return the data with the response.  A 200 OK response can also return no data if the developer chooses, but a 204 response should never return any data.  

300-level Responses:

A 300-level response indicates that a resource has been moved.  The most common of the 300-level responses is 301 Moved Permanently. This response should include the new URI in the header, so that the client will know where to point the request next time.  

400-level Responses:

A 400-level response indicates that there was something wrong with the client's request.  The most common of these is 400 Bad Request, which is usually used when the request is malformed or inaccurate in some way.  Examples of this would be a request where there is required data that is not present, or data that has some sort of validation error.  Other common 400-level responses include:

401 Unauthorized- this is usually returned when the client does not have the appropriate authentication to make the request, such as a JWT or a cookie.  

403 Forbidden- this is returned when the client has the appropriate authentication to make the request, but does not have the permission to view the resource.  For example, a user might be logged into the system and be able to request their own data, but should not be able to request another user's data.

404 Not Found- this is returned when the client is making a request for a specific resource, and the server cannot find it.  An example of this would be if a customer with an ID of 100 was requested, and there was no customer with an ID of 100 in the database. 

409 Conflict- this is returned when the request puts data resources in conflict with each other.  One example of this would be if the client was attempting a POST request to create a resource with an id that was already being used.  

500-level Responses:

A 500-level response means that something has gone wrong on the server side of the request.  The most common is the 500 Internal Server Error response, which can be used for a variety of problems.  An example of this would be a request that was attempting to add a record to a database where the database table is not equipped to handle it, because it has too many characters or is the wrong type. Other common 500-level responses include:

502 Bad Gateway- this can happen when the responding server needs to make a request from another server, and the other server is returning an invalid response.

503 Service Unavailable- this is returned when the responding server is temporarily down for some reason. This response can be more helpful than the generic 500 response, because it indicates that the problem is with availability rather than with the database. 

Now that we understand what response codes mean, let's try them out in our Postman Pet Store Collection!  If you have not yet created the collection, see last week's post for instructions.  Click on the first request in the collection: Add Pet.  Underneath the URL of the request, click on "Tests".  In the right-hand side of the window, there will be a list of code snippets that you can use to create assertions.  Scroll down until you find the snippet called "Status code: Code is 200", and click on it. This will automatically add an assertion in the test field that looks like this:  

pm.test("Status code is 200", function () {

    pm.response.to.have.status(200);

});

The "Status code is 200" section of this code is the name of the test you are running.  The "pm.response.to.have.status(200)" section is the expectation of the assertion.  

Click the Save button on the request, and then click the Send button.  In the bottom section of the page, you should see a Test Results section with a "(1/1)" after the section title.  This indicates that 1 test passed, and 1 test was run.  If you click on the Test Results link, you should see "PASS" and "Status code is 200" in the response section.  You have successfully added an assertion to your request!

Let's see what a failed assertion looks like.  To make the assertion fail, simple change the body of the assertion to:

pm.test("Status code is 202", function () {

    pm.response.to.have.status(202);

});

We have set our assertion to expect a 202 response instead of a 200.  Run the request again, and now you should see "(0/1)" next to the Test Results link.  Click on the link, and in the response section, you should see "FAIL" and "Status code is 202".  This indicates that the test named "Status code is 202" has failed.  

Now change the assertion back to expect a 200 response, and add the assertion to all of the other requests in your collection, except for the request called "Verify Delete Pet".  The "Verify Delete Pet" request is looking for a record that no longer exists, so we will not be expecting a 200 response.  Instead, we should be getting a 404 Not Found response.  Let's add this assertion in the Tests section of the request:

pm.test("Status code is 404", function () {

    pm.response.to.have.status(404);

});

Click the Save button to save this assertion.  

If you run this request before you have run the Delete Pet request, you will see the assertion fail, because the pet with the id of 100 still exists.  But if you first run the Delete Pet request, and then run the Verify Delete Pet request, you will see the Delete Pet assertion pass, because the pet with the id of 100 no longer exists in the database.

Now that we have assertions on all of our requests, let's try running the entire collection!  Hover over the name of the Pet Store collection, and click on the chevron (>) that appears to the right of the name.  Click on the "Run" button, and the Collection Runner will open.  Click on the name of your collection, and then click the "Run Pet Store" button.  You should see your tests run, and pass, very quickly!  Your results window should look like this:

At the top of the window, you'll see that your six tests passed, and that zero tests failed.  You'll see the name of each of the requests you created, and the name of each test that you ran for each request, along with the "PASS" indicator.

Next week we'll add some more interesting assertions to our collection!  

Creating a Postman Collection

This week we'll be finishing up our discussion of REST request types with an introduction to the DELETE request and how to test it.  We will also be looking at how to chain REST tests together in a Postman collection.

A DELETE request removes an entire record from a database table.  To see a DELETE request in action, let's return to the Swagger Pet Store.  First let's open up the GET /pet/{petId} request.  Click on the "Try it out" button, and put "100" in the petId field.  Then click the Execute button.  Take a look at the server response.  Was a pet returned?  If not, try a different petId.  Keep looking until you find an existing record.

Now that you have an existing record, open up the DELETE /pet/{petId} request and click on the "Try it out" button.  In the petId field, enter the same id that you used for the GET request.  Click the Execute button.  In the server response, you should see a success code of 200.

How can you tell that the record was really deleted?  Simply return to the GET request, put the same id in the petId field, and click the Execute button.  You should now get a "Pet not found" response.  You have successfully deleted a pet from the database!

Testing a DELETE request is fairly straightforward.  Since the only information you are passing into the request is the id of the record you want to delete, there's not much room for variation.  You can test what happens when you enter an id for a record that doesn't exist (you should get a 404 response) and what happens when you enter an invalid id such as "FOO".  If the DELETE functionality in your application is limited to users with authorization, you can try deleting a record without the token or cookie that gives you the required permission.  You can try sending the request with an http URL instead of an https (or vice versa), or you can try sending a URL that doesn't specify an id to delete.

Now let's go to Postman and try chaining some requests together!  Imagine that you are putting together a test suite for the Swagger Pet Store.  You'd like to check to make sure that you can add a pet, retrieve a pet, edit a pet, and delete a pet from the database.  When you add a pet to the database, you'd like to make sure the record has really been added; so you'd like to have a GET request to verify that.  Similarly, when you edit the pet, you'd like to do a GET request to verify that the pet has been changed.  And finally, when you delete the pet, you'd like to do a GET request to verify that the pet has really been deleted.  Also, you'd like to have your test suite clean up after itself, so you aren't adding more and more records to your database each day.  Chaining your requests together in a Postman collection will accomplish all of this.  This is the order of requests that you will make:

POST pet- to add the pet to the database
GET pet- to verify that the pet has been added
PUT pet- to change the existing pet
GET pet- to verify that the pet has been changed
DELETE pet- to remove the pet from the database
GET pet- to verify that the pet has been removed

To create a Postman collection, first click on the Collections tab on the top left of the screen. Then click on the icon with the folder and plus sign:

Give your collection a name, such as "Pet Store", and click the Create button.  You will see a folder with your collection name in the left column of the screen.  Now click on the "+" tab in the main window of the screen to add a new request.  We'll start with the POST pet request.  Create the request like this:

Request type: POST
URL: http://petstore.swagger.io/v2/pet
Headers: Content-Type: application/json
Body:
{
  "id": 100,
  "category": {
    "id": 1,
    "name": "cat"
  },
  "name": "Grumpy Cat",
  "photoUrls": [
    "https://pbs.twimg.com/profile_images/948294484596375552/RyGNqDEM_400x400.jpg"
  ],
  "tags": [
    {
      "id": 1,
      "name": "blue eyes"
    }
  ],
  "status": "sold"
}

If any of this seems unfamiliar, you can see more detailed instructions in my post on POST requests.  

Once the request is ready and working, you can save it to your collection.  Click on the Save button in the upper right of the screen.  A popup window will appear.  Give your request a name, such as "Add Pet", and then select the collection that you created earlier.  Click the Save button, and you should now see your request in the collection folder on the left of the screen.

We can repeat this process with the GET request:

Request type: GET
URL: http://petstore.swagger.io/v2/pet/100

As soon as this request is working, save it to your collection with a name like "Verify Add Pet".  We are calling the request this because we will be using it to verify that the previous POST request worked correctly.

Next, we'll edit the pet with a PUT request:

Request type: PUT
URL: http://petstore.swagger.io/v2/pet
Headers: Content-Type: application/json
Body:

{

  "id": 100,

  "category": {

    "id": 2,

    "name": "Dog"

  },

  "name": "Droopy Dog",

  "photoUrls": [

    "https://upload.wikimedia.org/wikipedia/en/thumb/f/fd/Droopy_dog.png/150px-Droopy_dog.png"

  ],

  "tags": [

    {

      "id": 2,

      "name": "Beagle"

    }

  ],

  "status": "pending"

}

Once this request is working, save it to your collection with a name like "Update Pet".

Now we'll want to do another GET request, to verify that the PUT request worked correctly.  We already have a GET request saved, so we can just duplicate it in our collection.  Hover over the "Verify Add Pet" request on the left of the screen, and you'll see three dots appear to the right of the request name.  Click on the three dots and choose "Duplicate".  You should now have a request below the original "Verify Add Pet" request that says "Verify Add Pet copy".  Click on this request and then on the three dots beside it and choose "Rename".  Rename your request to "Verify Update Pet", and click return.  Since we will be using this GET request to verify that the PUT request worked correctly, click and hold on the request and drag it below the PUT request.  

Next we'll want to create a DELETE request:

Request type: DELETE
URL: http://petstore.swagger.io/v2/pet/100

Save this request to your collection with a name like "Delete Pet".

Finally, we'll want to do one more GET request, to verify that the DELETE request removed the pet correctly.  Duplicate the "Verify Update Pet" request, rename the copied request to "Verify Delete Pet", and move it below the DELETE request.  Remember that when you run this request after your delete, you should get a "Pet not found" response.

We now have a collection with six requests that can be used to test the pet function of the Pet Store!  It should look like this:

Try clicking on each of these requests in order and using the blue Send button in the top right of the screen to run each one.  You should be able to add a pet, verify that it has been added, update the pet, verify that it has been updated, delete the pet, and verify that it has been deleted.

We will use this collection in the next couple of weeks to create assertions that will turn these requests into true tests.  Next week, we'll discuss response codes and what they mean; then we'll put some response code assertions into our requests.  Until then, have fun playing around with your Pet Store collection!

Testing PATCH Requests

Like PUT requests, PATCH requests modify an existing record.  But PATCH requests are much tricker to test!  This is because a PUT request modifies an entire record, whereas a PATCH request modifies only one part of the record.  There are many different operations that you can do within a PATCH request: you can add, replace, remove, copy, and move a value in your record.  I'll describe some examples of each and discuss the various ways you can test them. 

Let's use a very simple example of a data record for patching:

The JSON description of the first record would look like this:

{

    "id": "1",

    "firstName": "John",

    "lastName": "Smith",

    "homePhone": "8005551000",

    "workPhone": null

}

Notice that our first record does not have a work phone.  Let's do an add operation with our PATCH request in order to add one:

The URL for the request would look something like: https://app/customer/1, where the "1" is representing the id of the customer that you want to patch, and of course the http verb used should be PATCH.  The body of the request would look like this:

[

    {"op":"add","path":"/workPhone","value":"8005551001"}

]

The "op" in this case is referring to the operation that you want to do for your PATCH.  Here we are using an add operation.  The "path" is showing which field you would like to add a value to, in this case the work phone field; the "value" is value that you want to add to that path, in this case the phone number itself.  

When this operation is completed, the JSON description will look like this:

{

    "id": 1,

    "firstName": "John",

    "lastName": "Smith",

    "homePhone": "8005551000",

    "workPhone": "8005551001"

}

Here are some ways to test a PATCH add operation:

• Happy Path- patching where there is currently a null value
• patching over the null value with an empty value of ""- this should add an empty string
• patching over an empty value of ""- this should replace the existing empty string
• patching over an existing value- this will replace the existing value, but ideally the replace operation should be used here instead
• adding a value with too many or too fewer characters than allowed- an appropriate error message should be returned
• adding a value with characters that are not allowed- an appropriate error message should be returned
• adding a value of the wrong type, such as adding an integer when a string is expected- an appropriate error message should be returned

Next, let's take a look at the replace operation.  Let's use the second record this time, and we'll replace the home phone.  This is what the record currently looks like:

{

    "id": 2,

    "firstName": "Amy",

    "lastName": "Jones",

    "homePhone": "8005551002",

    "workPhone": "8005551003"

}

The URL for the request will be https://app/customer/2, because we are patching the second record, and the body of the request will be:

[

    {"op":"replace","path":"/homePhone","value":"8005551111"}

]

This operation will replace the original home phone of 8005551002 with a phone number of 8005551111, so the record will now look like this:

{

    "id": 2,

    "firstName": "Amy",

    "lastName": "Jones",

    "homePhone": "8005551111",

    "workPhone": "8005551003"

}

To test a PATCH replace operation, here are some things that you can try:

• Happy Path- replacing one value with another
• replacing the value with null- a remove operation would be better for this, but this should still work
• replacing the value with the empty string ""- this should work
• replacing a null value with a value- this will probably work, but it would be better to use the add operation
• replacing with a value with too many or too fewer characters than allowed- an appropriate error message should be returned
• replacing with a value with characters that are not allowed- an appropriate error message should be returned
• replacing with a value of the wrong type, such as adding an integer when a string is expected- an appropriate error message should be returned
• replacing where the existing value is bad in some way, such as having too many characters or having the wrong format- in this case the new good value should be allowed to replace the bad old value

Now let's look at the remove operation.  We'll start with this record:

{

    "id": 1,

    "firstName": "John",

    "lastName": "Smith",

    "homePhone": "8005551000",

    "workPhone": "8005551001"

}

To remove the home phone of this customer, we would again use this URL: app/customer/1, and we would use this body:

[

    {"op":"remove", "path":"/homePhone"}

]

We will get this as a result:

{

    "id": "1",

    "firstName": "John",

    "lastName": "Smith",

    "homePhone": null,

    "workPhone": "8005551001"

}

A remove operation is fairly easy to test.  We just need to verify that the value has indeed been removed and replaced with null.  It's also good to verify that no other value was removed by mistake, such as removing both phone numbers instead of just the home phone. We can also test that it's not possible to remove a required field- this should return an appropriate error message.  

Now let's look at the move operation.  Looking at the previous state of John's record, let's imagine that we have it wrong, and that what we have for his work phone is actually his home phone.  To move the phone number, we would use this request body:

[

    {"op":"move","from":"/workPhone","path":"/homePhone"}

]

In this example, the "from" indicates where the current value is, and the "path" indicates where you would like the value to move to.  After this operation, our record will look like this:

{

    "id": "1",

    "firstName": "John",

    "lastName": "Smith",

    "homePhone": "8005551001",

    "workPhone": null

}

Here are some ideas for testing a move operation:

• Happy Path- moving an existing value to a location where the value is currently null
• moving an existing value from location A to location B, where there is already a value in location B- in this case, the value in location B will be replaced with the value that was in location A
• doing a move from A to B where the value of A is null- this should return an appropriate error message, because there's nothing to move
• doing a move from A to B where the validation constraints are different in location B, so A's value should not be allowed- this should return an appropriate error message
• doing a move from A to B where the value in A is bad- this should return an appropriate error message
• moving a value from one location to a location that does not exist: this should return an appropriate error message

Finally, we'll look at the copy operation.  This will copy an existing value and put it in a different location.  Let's take this example:

{

    "id": "1",

    "firstName": "John",

    "lastName": "Smith",

    "homePhone": "8005551001",

    "workPhone": null

}

If we want to copy the home phone so that the work phone will be the same number, we can do this request:

[

    {"op":"copy","from":"/homePhone","path":"/workPhone"}

]

The "from" field shows us the location of the value we want to copy, and the "path" field shows us the location we'd like to copy to.  Our record should now look like this:

{

    "id": "1",

    "firstName": "John",

    "lastName": "Smith",

    "homePhone": "8005551001",

    "workPhone": "8005551001"

}

Testing a copy operation is very similar to testing a move operation:

• Happy Path: copying a value from one location to another where the value is currently null
• copying a value from location A to location B, where location B currently has a value; this value will be replaced by the value in location A
• copying from location A where the value of A is null- this should return an error message
• copying from location A to a location that does not exist- this should return an error message
• copying from A to B where the validation constraints are different in location B- this should return an error message
• copying a bad value from location A to location B- this should return an error message

An important thing to note when patching is that PATCH requests can be chained together.  For example, if we start with this scenario:

{

    "id": 2,

    "firstName": "Amy",

    "lastName": "Jones",

    "homePhone": "8005551002",

    "workPhone": "8005551003"

}

And we run this PATCH request:

[

    {"op":"remove","path":"/homePhone"},

    {"op":"replace","path":"/workPhone","value":"8005551111"}

]

We will wind up with this result:

{

    "id": 2,

    "firstName": "Amy",

    "lastName": "Jones",

    "homePhone": null,

    "workPhone": "8005551111"

}

When we chain together requests in a PATCH, we need to test that any invalid operation will result in the entire request being invalid.  For example, if we had instead tried this request:

[

    {"op":"remove","path":"/homePhone"},

    {"op":"replace","path":"/workPhone","value":"NOTAPHONENUMBER"}

]

we should receive an error message, and the first part of the PATCH should NOT have been executed.  In other words, we should still have a value in for the home phone.  

As you can see, PATCH requests are almost a set of HTTP verbs in themselves!  They should be used very carefully in an application, because there are so many different ways they can go wrong.  If your application is using them, be sure to test them alone and in combination.  Be sure to test both the Happy Path and the many ways they can fail validation.  If you are able to put bad data into your database, be sure to test patching over bad data.  

In next week's post, I'll discuss the DELETE request, and also how to create a Postman collection!  

Testing PUT Requests

In last week's blog post, we discussed how to create and test POST requests.  This week, we will tackle testing PUT requests.  A PUT request is actually very similar to a POST request; the major difference is that POST requests are intended to create a new record, and PUT requests are intended to replace an existing record.

Let's return to the Swagger Pet Store to learn how to create a PUT request.  Click on the PUT /pet request to open it:

As you can see, the endpoint and the body of the request are exactly the same as that of the POST request.  The only difference is the http verb used: PUT instead of POST.  To see how the PUT request works, let's first do a POST with these values:

{

  "id": 1,

  "category": {

    "id": 1,

    "name": "Cat"

  },

  "name": "Grumpy Cat",

  "photoUrls": [

    "https://pbs.twimg.com/profile_images/948294484596375552/RyGNqDEM_400x400.jpg"

  ],

  "tags": [

    {

      "id": 1,

      "name": "Mixed breed"

    }

  ],

  "status": "available"

}

Then do a GET to make sure that the pet was added correctly.  Now, let's do a PUT with these values:

{

  "id": 1,

  "category": {

    "id": 2,

    "name": "Dog"

  },

  "name": "Droopy Dog",

  "photoUrls": [

    "https://upload.wikimedia.org/wikipedia/en/thumb/f/fd/Droopy_dog.png/150px-Droopy_dog.png"

  ],

  "tags": [

    {

      "id": 2,

      "name": "Beagle"

    }

  ],

  "status": "pending"

}

Notice that all of the values in the body of the request have been changed except for the pet id. After you have submitted the request, do a GET to confirm that all of the values have been replaced.

A PUT request will always replace ALL of the values in the entire record, which means that if any of the values are missing, they will be removed.  For example, if we did a PUT request on that same pet id, and only included a name and a photo URL, that will be all that will be saved. Any tag or status that was present in the record before will now be gone.  

To talk about testing PUT requests, I'm going to move away from the Swagger Pet Store and use a different example. Let's consider an application that stores a list of employees.  The application writes to a table that has these values:

The PUT request that will be used to update a record in the table will look like this:

{

  "firstName": "Amy",

  "lastName": "Miller"

}

And the URL of the request will look like this: app/employee/1.  In this application, the employee id is passed in through the URL, rather than the body of the request, which is a common practice.  

The first thing we will test in our imaginary application is the Happy Path: if we send this request, does employee 1 now have the name Amy Miller instead of Fred Smith?  You could check this by querying the database directly, and by doing a GET request.  

Next, we'll see what happens when trying to do a PUT request on a record that doesn't exist.  Imagine doing the same request, but instead of using the URL app/employee/1, we'll use app/employee/3.  As you can see in the data table, there is no record 3.  So this request should return an error, such as a 404 Not Found response.  You can also try passing in ids that make no sense, such as letters, words, or symbols, and passing in no id at all.  All these requests should return an appropriate error message.

Now let's turn to the body of our request.  Let's imagine that both the firstName and the lastName are required for the PUT request.  We should get an appropriate error message if we send in an empty body, or just the firstName, or just the lastName.  In a scenario where there are many more fields than we have here, you'll want to test lots of different combinations where required and non-required fields are missing.  

As I mentioned above, a PUT request should replace ALL the values in a record; it's like the record was completely removed and replaced with a brand new one.  So if we consider for a moment a scenario where the firstName is NOT required, and record 1 is currently Amy Miller, and we do a test where we send in only a lastName of "Brown", record 1 should now have a NULL value for the firstName, and Brown should be the lastName.  

You could also see what happens when you try to pass in a request with fields that aren't in the table at all!  In this example, you could try sending in 

{

  "firstName": "Amy",

  "middleName": "Jo"

  "lastName": "Miller"

}

and verify that the field is either ignored or an appropriate message is returned.  

Now we can go on to the individual fields themselves. What sort of values are allowed? What are the character limits?  You'll want to test each individual field to make sure that you receive an appropriate error message when the limits are violated, and that you receive an appropriate error message when you try to pass in characters or values that are not allowed.  You'll also want to try sending in values that could be used for cross-site scripting or SQL injection; these should either be rejected outright or sanitized in such a way that a malicious attack would not work.  

Finally, you can return to the http verb and the general request.  What happens if you change the PUT request to a POST request?  In our hypothetical application, a POST request with a URL of app/employee/1 will return a 409 error, because record 1 already exists.  You can also see what happens if you remove or change required headers on the request.  

Hopefully this post has given you a clear indication of how PUT requests behave, and the best ways to test them.  Next week, we'll be on to the lesser-used PATCH request!  

Testing POST Requests

Last week, I introduced the concept of the GET request and how to test it.  This week we'll move to POST requests.  POST requests are perhaps the most important of the RESTful requests, because they are what adds new records to your application's database.  It's very important to test your POST requests well, because they will have a direct impact on the quality of data in your database.

To learn about POST requests, we'll once again use the Swagger Pet Store and Postman.  Navigate to the Pet Store (http://petstore.swagger.io) and click on the first POST request listed: "/pet".  This POST request will add a pet to the pet store.  Take a look at the Example Value shown:

This is the body of the POST request.  Unlike GET requests, which usually don't have a body, you will usually find some json or xml in a POST request.  The body represents the data that you are adding to the database.  Now click on the Model link:

This describes a bit about what all of the values in the body are.  You can click on the ">" icons to open up each section of the model.  I find this model to be a bit vague in terms of defining what a category is and what tags are, so I'm going to do a little guesswork.  Let's walk through each section of the Pet model:
id: this is the id of the pet, which can be used in the GET request we tested last week
category: this represents what kind of animal the pet is.  The id is the unique identifier for the category, and the name is the word describing the animal.
name: this is the pet's name
photoUrls: these are strings that link to pictures of the pet
tags: these are descriptive phrases that can be added to the pet.  The id is the unique identifier for the tag, and the name is the descriptive word describing something about the pet
status: this is the status of the pet in the store.  The status can be available, pending, or sold.

We can use the information in the model to create a POST to make a new pet.  Click on the "Try it out" link, and replace the body of the request with this information:
{
  "id": 102,
  "category": {
    "id": 1,
    "name": "cat"
  },
  "name": "Grumpy Cat",
  "photoUrls": [
    "https://pbs.twimg.com/profile_images/948294484596375552/RyGNqDEM_400x400.jpg"
  ],
  "tags": [
    {
      "id": 1,
      "name": "blue eyes"
    }
  ],
  "status": "sold"
}

Before you click the Execute button, I do want to point out something in this POST request that is different from what you will most likely experience in the applications you test.  Generally, when you post an object with an id and that id already exists in the database, you'll get a message that the record already exists.  In the case of the Pet Store, if that id already exists in the database, it will get overwritten with the object that you have posted.  

Now click the "Execute" button.  Take a look at what was returned in the body of the response.  You should see all the data you added.  It may be in a different order than it was in the body of the request, but that's not important.

Let's test to make sure that the new pet was really added!  Return to the GET pet/{petId} request, open it up, and click "Try it out".  Enter "100" into the id field, and click "Execute".  You should see the pet you added in the body of the response.  

Now that you have created a successful request in Swagger, let's try one in Postman.  Open up the Postman application, and click on the plus button (+) to create a new request.  Click on the dropdown icon next to the word "GET" and choose "POST" instead.  Enter in the request URL: http://petstore.swagger.io/v2/pet. Click on the "Body" tab underneath the URL and select the "Raw" option.  In the body section just underneath, paste the request that you used earlier in Swagger.  You may want to vary it slightly by changing the id or the pet's name.  

There's one more step we need to do before we can send this request in Postman, and that is to add a header.  Headers are used in HTTP requests and responses to pass additional information to the server.  In this case, we need to tell the server what content-type to expect.  Click on the "Header" tab underneath the URL.  In the space underneath "Key", add "Content-Type".  In the space underneath "Value", add "application/json".  In this way, we are telling the server that it should look for a body in json format when we send our request.  Now click the "Send" button.  In the bottom half of the Postman window, you should see a 200 response code, and a response body that has all of the data you added.  Now you can use a GET request in Postman to check to make sure that your pet was added.  Return to last week's blog post if you need help setting that up.  

Just as we found when we discussed testing forms, there are many different scenarios to test when testing POST requests.  First, we'll want to test many Happy Path scenarios.  Try a number of different POSTs where you vary the id, the category of the pet and its id, the pet's name, the photo URL, the tag and the tag's id, and the status of the pet. You'll want to make sure to test all three statuses of the pet: sold, available, and pending.  Also note that it's possible to pass in more than one photo URL, and more than one tag.  Here's an example of a body of a POST request where three photos and two tags are passed in:

{

  "id": 102,

  "category": {

    "id": 2,

    "name": "dog"

  },

  "name": "Snoopy",

  "photoUrls": [

    "https://schulzmuseum.org/wp-content/uploads/2017/06/920608_FlyingAce-200.jpg",

    "https://www.calmuseums.org/images/snoopy/snoopy.png",

    "https://vignette.wikia.nocookie.net/peanuts/images/2/28/AmigosperdemoSono.png/revision/latest?cb=20110823202539"

  ],

  "tags": [

    {

      "id": 2,

      "name": "beagle"

    },

    {

      "id": 3,

      "name": "flying ace"

    }

  ],

  "status": "available"

}

Now that you have tested a number of Happy Path scenarios, it's time to think about breaking the request.  First, you may have noticed in the Swagger Model that only two fields are required: the name of the pet, and one photo URL.  What happens if you pass in just those two fields?  

{

  "name": "Snoopy",

  "photoUrls": [

    "https://schulzmuseum.org/wp-content/uploads/2017/06/920608_FlyingAce-200.jpg"

  ]

}

We get a 200 response, and the pet has been added with an id that we can use to retrieve it.  What happens if there are no values in the body of the request?  What happens if one of the required fields is missing?  Now is a good time to experiment by passing in a variety of combinations of fields.  

It's worth noting at this point that you may get a 500 response for nearly every error condition you provoke.  In a real-world application, you'd get more appropriate response codes with more appropriate error messages. 

Next, it's time to take another look at passing in multiple URLs and tags.  How many URLs can you pass in before provoking an error?  How many tags can you pass in before you get an error?  

Now we'll look at the limits of the values we are passing in.  For example, what happens if you create a pet with an id of 0?  What happens if you create one with the id of -100000?  What happens if you send in an id of "FOO" or $%^?  You can test this on all of the ids: the pet's id, the category id, and the tag id.  How long are the text strings allowed to be?  How short are they allowed to be?  Are there any characters that are not allowed?  You'll want to test the upper and lower limits of the strings, and verify that any forbidden characters are not allowed.  This is also a good time to test for SQL injection and cross-site scripting.  For example, you could try passing in 

<script>alert('XSS')</script> 

or 

' or 1 = 1-- 

and see if those are allowed.  (In the case of the Pet Store, these will probably be allowed, but a real application should forbid these or at least render them ineffective.)  

Another thing to test is the enum field for the pet's status.  The pet's status should be limited to available, pending, and sold.  What happens if you pass in another word or number or symbol?  What happens if you pass in a valid status with all caps, or with some of the letters capitalized?  A POST request should generally be case-insensitive.  You will also want to test the photo URL, making sure that you can't pass in malicious scripts, and making sure that you can't pass in something that isn't a URL.

Once you have finished testing the body of the request, you can test the headers of the request.  This particular POST request requires a Content-Type header, and it will allow either an application/json header or an application/xml header.  If the header is missing, you'll get a 415 error.  If you use an application/xml header, you'll get a 400 error, unless you first change the body of the request to be in XML format.  You could also test to see what happens when you send an xml body with an application/json header.  

Finally, you can test the URL of the request itself, and the request type.  What happens if you make the request an https request?  What happens if you change the POST request to a GET?  

In summary, there are many ways to test POST requests, many of which would not be possible if you were focusing only on the UI.  In addition to testing required and non-required fields and field validation, you can also manipulate the object passed into the database and the headers and URL used to make the request. 

Next week, we'll move on to PUT requests!