Introduction to REST Requests

More and more companies are moving toward a microservices model for their applications.  This means that different sections of their application can have a separate datastore and separate commands for interacting with that datastore.  The advantage to this is that it's easier to deploy changes to a small component of the application rather than the entire application; it also means that if one microservice goes down, the rest of the application can continue to function.  For example, let's imagine you have a website for a bike rental service.  The site has a microservice for the reservation system, and a second microservice for the inventory.  If the microservice for the inventory goes down, users will still be able to make reservations for bike rentals, using cached data from the inventory microservice.

Most microservices are using APIs, or Application Programming Interfaces, which are a set of commands for how a service can be used.  And most APIs are using REST requests, or Representational State Transfers, through HTTP to request and send data.

Yet in spite of the common usage of RESTful APIs in today's applications, many testers do not know just how easy it is to test them!  This post will serve as a gentle introduction to REST requests for use in API testing.

Why would you want to test REST requests, rather than just wait and test through the UI?  Here are a few good reasons:

• testing REST requests means that you can find bugs earlier in the development process, sometimes even before the UI has been created!
• malicious users know how to make REST requests, and can use them to exploit security flaws in your application by making requests the UI doesn't allow
• it's easy to automate REST requests, and they run MUCH faster than UI automation (see my earlier blog post for further discussion of API vs. UI automation)

To get started in RESTful testing, first think about what you see in a URL when you navigate to a website.  For example, you might see: https://www.foobank.com/customers/login.  It's easy to see how this URL is defining what page you are navigating to:

• the https is specifying that this is a secure request
• the www.foobank.com is the domain, which says that you want to go to the Foobank website
• the customers is the first part of the path, which says that you are a customer and therefore want to go the Customers section of the website
• the login is the last part of the path, which says that you want to go the login screen

One thing that's not seen in the URL is the type of RESTful request being made.  This is known as an HTTP verb, and they are easy to understand:

• a POST request adds a new record to the database
• a GET request retrieves a record from the database
• a PUT request takes a record from the database and replaces it with a new record
• a PATCH request modifies an existing record in the database
• a DELETE request removes a record from the database

In this case, a "record" can be any section of data that is grouped together.  For example, it could be a mailing address for a customer; or it could be all of the contact information for that customer; or it could be every single datapoint associated with that customer.  It's up to the creators of the API to decide what should make up the record.  

In the next several blog posts, I'll discuss each of the HTTP verbs in detail and describe how to test them.  I am sure you will be excited to discover just how much you can test without even navigating to your application's web pages!