Using CURL to Test Your Rails API

As a full-stack developer, I normally begin my building process with the backend, or the API.

I always start with defining my routes, then generating models and controllers, some seeds, and maybe a validation or two.

One mistake I would regularly make was to write and build a plethora of features but not stop and take a minute to test it. This mistake can be very costly. Even if you are confident, it never hurts to stop and test something before building even further. The more you build without testing, the bigger the headache if something goes wrong. Imagine spending a few hours navigating your stack only to find a typo was breaking your entire application. Pretty frustrating, right?

When testing your backend with a full MVC structure such as Rails, the best way to test it is through the views in your browser. The browser will then either display what you were hoping to see or display an error telling you where you went wrong. However, with an API, we explicitly skip the views in favor of a frontend framework that will handle the client side in a more responsive manner. So how do we test our API without having to build out a frontend first? Enter CURL.

CURL is an open-source software project that will allow you to send requests to a server through the command line. Assuming we have an API with data on animals, through curl, we can send a request to localhost:3000/animals to hit our index action and receive a JSON object full of animals.

curl http://localhost:3000/animals

Navigating to localhost:3000/animals will produce the same result, however. CURL defaults to a get request unless you specify otherwise. We can’t simply navigate to delete and edit routes in our browser, so this is where CURL really shines.

In order to use a different HTTP very such as POST, PATCH or DELETE, we need to prepend our CURL statement with -x. If we wanted to delete the first animal in our database, our request would look like this:

curl -x DELETE http://localhost:3000/animals/1

Easy enough. However, with a POST request, we will be sending data to our server. To do so, we need -d to denote data being sent. A post request to add an animal to our database would look like this:

curl -d "animal[name]=Milo" -d "animal[age]=5" http://localhost:3000/animals/new

Since we are using -d, CURL automatically knows we are sending a POST request. It is important to note that using this method requires us to include -d for every parameter sent.

POST requests can also be sent in JSON format, with headers included as well. A POST request in that format looks like this:

curl -H "Content-Type: application/json" -H "Accept: application/json" -d '{"name": "Milo", "age": "5"}' http://localhost:3000/animals/new

We add -H flags here to denote headers that basically tell our server that the parameters are going to be in JSON format.

To summarize, sending a CURL request to a running server will allow you to test your routes and controllers without building a frontend.

By default, CURL uses GET as it’s HTTP verb.

-X allows you to specify the HTTP verb you want to use

-d is placed before the parameters, and tells CURL to use POST as the verb by default

-H denotes any Headers you want to send in your request to make it more similar to JavaScript’s fetch() method.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store