Skip to main content

Testing REST API Endpoints

HTTPSpec is ideal for testing REST APIs. Here’s how to test different HTTP methods:
### Fetch user data
GET https://jsonplaceholder.typicode.com/users/1
Accept: application/json

//# status == 200
//# body contains "Leanne Graham"

Checking Response Headers

Validate that your API returns the correct content type and other headers:
### Verify JSON response headers
GET https://httpbin.org/json
Accept: application/json

//# status == 200
//# header["content-type"] contains "application/json"
Header names are case-insensitive. Use the format header["header-name"] to check specific headers.

Common Header Checks

//# header["content-type"] == "application/json"
//# header["content-type"] contains "json"

Body Content Validation

HTTPSpec provides several ways to validate response bodies:

Exact Match

Check if the body exactly matches a string:
GET https://api.example.com/health

//# body == "OK"

Contains Check

Verify the body contains specific content:
### Test JSONPlaceholder API
GET https://jsonplaceholder.typicode.com/users/1
Accept: application/json

//# status == 200
//# body contains "Leanne Graham"
//# body contains "@hildegard.org"

Not Contains

Ensure the body doesn’t contain sensitive or error data:
GET https://api.example.com/public/users

//# body not_contains "password"
//# body not_contains "secret"
//# body not_contains "error"

Real-World Example: HTTPBin Testing

Here’s a complete example testing the HTTPBin API:
### Make a simple 200 request to HTTP Bin
GET http://httpbin.org/status/200
Content-Type: application/json

### Make a simple 404 request to HTTP Bin
GET http://httpbin.org/status/404
Content-Type: application/json

//# status == 404
This example demonstrates how HTTPSpec handles different status codes. The second request explicitly checks for a 404 response.

Sequential API Operations (CRUD Pattern)

Test a complete workflow by chaining requests:
### Create a new resource
POST https://api.example.com/posts
Content-Type: application/json
Authorization: Bearer TOKEN

{
  "title": "Test Post",
  "body": "This is a test post",
  "userId": 1
}

//# status == 201
//# body contains "id"
//# header["content-type"] contains "application/json"

### Read the created resource
GET https://api.example.com/posts/1
Accept: application/json
Authorization: Bearer TOKEN

//# status == 200
//# body contains "Test Post"
//# body contains "This is a test post"

### Update the resource
PUT https://api.example.com/posts/1
Content-Type: application/json
Authorization: Bearer TOKEN

{
  "title": "Updated Test Post",
  "body": "This post has been updated",
  "userId": 1
}

//# status == 200
//# body contains "Updated Test Post"

### Delete the resource
DELETE https://api.example.com/posts/1
Authorization: Bearer TOKEN

//# status == 204
Requests are executed sequentially in the order they appear. This is perfect for testing workflows, but be aware that later tests may depend on earlier ones succeeding.

Testing Different Status Codes

HTTPSpec makes it easy to test various HTTP status codes:
### Test 200 OK
GET http://httpbin.org/status/200
//# status == 200

### Test 201 Created
GET http://httpbin.org/status/201
//# status == 201

### Test 204 No Content
GET http://httpbin.org/status/204
//# status == 204

Authentication Testing

Test various authentication methods:
### Test with Bearer token
GET https://api.example.com/protected
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

//# status == 200
//# body contains "authenticated"

Best Practices for API Testing

Always test both successful responses and expected failures:
### Valid request should succeed
GET https://api.example.com/users/1
//# status == 200

### Invalid ID should fail
GET https://api.example.com/users/999999
//# status == 404
Use contains to check for expected fields in JSON responses:
//# body contains "id"
//# body contains "email"
//# body contains "created_at"
Ensure your API returns proper headers:
//# header["content-type"] == "application/json"
//# header["x-api-version"] == "v1"
Create separate test files for different environments:
  • api-test-dev.http - Development API
  • api-test-staging.http - Staging API
  • api-test-prod.http - Production smoke tests

Next Steps

Advanced Assertions

Learn about regex matching, negation, and complex assertions

Basic Tests

Back to basic testing examples

Build docs developers (and LLMs) love