curl-rest
Test a REST API with curl
Further reading:
Testing Web APIs with Postman Collections
Learn how to create a Postman Collection that can test a REST API
A Guide to REST-assured
Explore the basics of REST-assured – a library that simplifies the testing and validation of REST APIs.
2. Command-line Options
curl supports over 200 command-line options. And we can have zero or more of them to accompany the URL in the command.
But before we use it for our purposes, let’s take a look at two which would make our lives easier.
2.1. Verbose
curl -v http://www.example.com/As a result, the commands would provide helpful information such as the resolved IP address, the port we are trying to connect to and the headers.
3. HTTP Methods with curl
3.1. GET
This is the default method when making HTTP calls with curl. In fact, the examples previously shown were plain GET calls.
While running a local instance of a service at port 8082, we’d use something like this command to make a GET call:
curl -v http://localhost:8082/spring-rest/foos/9And since we have the verbose mode on, we’d get a little more information along with the response body:
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8082 (#0)
> GET /spring-rest/foos/9 HTTP/1.1
> Host: localhost:8082
> User-Agent: curl/7.60.0
> Accept: */*
>
< HTTP/1.1 200
< X-Application-Context: application:8082
< Content-Type: application/json;charset=UTF-8
< Transfer-Encoding: chunked
< Date: Sun, 15 Jul 2018 11:55:26 GMT
<
{
"id" : 9,
"name" : "TuwJ"
}* Connection #0 to host localhost left intact3.2. POST
The simplest way of doing this is to embed the data in the command:
curl -d 'id=9&name=baeldung' http://localhost:8082/spring-rest/foos/newor, pass a file containing the request body to the data option like this:
curl -d @request.json -H "Content-Type: application/json"
http://localhost:8082/spring-rest/foos/newBy using the above commands as they are, we may run into error messages like the following one:
{
"timestamp" : "15-07-2018 05:57",
"status" : 415,
"error" : "Unsupported Media Type",
"exception" : "org.springframework.web.HttpMediaTypeNotSupportedException",
"message" : "Content type 'application/x-www-form-urlencoded;charset=UTF-8' not supported",
"path" : "/spring-rest/foos/new"
}This is because curl adds the following default header to all POST requests:
Content-Type: application/x-www-form-urlencodedThis is also what the browsers use in a plain POST. In our usage, we’d usually want to customize the headers depending on our needs.
For instance, if our service expects json content-type, then we can use the -H option to modify our original POST request:
curl -d '{"id":9,"name":"baeldung"}' -H 'Content-Type: application/json'
http://localhost:8082/spring-rest/foos/newWindows command prompt has no support for single quotes like the Unix-like shells.
As a result, we’d need to replace the single quotes with double quotes; escaping them wherever necessary:
curl -d "{\"id\":9,\"name\":\"baeldung\"}" -H "Content-Type: application/json"
http://localhost:8082/spring-rest/foos/newBesides, when we want to send a somewhat larger amount of data, it is usually a good idea to use a data file.
3.3. PUT
This method is very similar to POST. But we use it when we want to send a new version of an existing resource. In order to do this, we use the -X option.
Without any mention of a request method type, curl defaults to using GET. Therefore, we explicitly mention the method type in case of PUT:
curl -d @request.json -H 'Content-Type: application/json'
-X PUT http://localhost:8082/spring-rest/foos/94. Custom Headers
For instance, to change the Host header, we do this:
curl -H "Host: com.baeldung" http://example.com/To switch off the User-Agent header, we put in an empty value:
curl -H "User-Agent:" http://example.com/The most usual scenario while testing is changing the Content-Type and Accept header. We’d just have to prefix each header with the -H option:
curl -d @request.json -H "Content-Type: application/json"
-H "Accept: application/json" http://localhost:8082/spring-rest/foos/new5. Authentication
A service that requires authentication would send back a 401 – Unauthorized HTTP response code and an associated WWW-Authenticate header.
For basic authentication, we can simply embed the username and password combination inside our request using the user option:
curl --user baeldung:secretPassword http://example.com/However, if we want to use OAuth2 for authentication, we’d first need to get the access_token from our authorization service.
The service response would contain the access_token:
{
"access_token": "b1094abc0-54a4-3eab-7213-877142c33fh3",
"token_type": "bearer",
"refresh_token": "253begef-868c-5d48-92e8-448c2ec4bd91",
"expires_in": 31234
}Now, we can use the token in our Authorization header:
curl -H "Authorization: Bearer b1094abc0-54a4-3eab-7213-877142c33fh3" http://example.com/6. Conclusion
We looked at using the bare-minimum functionality of curl to test our REST services. Although it can do much more than what has been discussed here, for our purpose, this much should suffice.
Feel free to type curl -h on the command line to check out all the available options. The REST service used for the demonstration is available here on GitHub.
