assert_
glossary ↓ downloads
track: java · selenium
suite 06 · api automation

REST in 15 minutes

API automation15 min
as a manual tester

You test what the screen shows. When it's wrong, you file it against 'the app'.

→
in automation

Behind every screen is an API sending the data. Test the API directly and you find bugs earlier, faster, and without a browser at all.

Modern apps are split: a frontend (the UI) and a backend exposing an API — URLs that accept requests and return data, usually as JSON. API tests skip the browser entirely: no locators, no waits, no flakiness, and they run in milliseconds. Many career-changers find this easier than UI automation — it's a genuine early win.

The anatomy of a request

one request, one response — the whole conversation
Your test REST Assured · JUnit given().when().get(…) API server jsonplaceholder.typicode.com no UI. just data. GET /users/1 200 OK · JSON body { "name": "Leanne…",   "address": { "city": … } } no browser anywhere in this picture — that's why API tests run in milliseconds

Make your first API call — no code required

Windows ships curl. In PowerShell:

PowerShell
curl.exe https://jsonplaceholder.typicode.com/users/1
output — JSON response
{
  "id": 1,
  "name": "Leanne Graham",
  "username": "Bret",
  "email": "Sincere@april.biz",
  "address": {
    "street": "Kulas Light",
    "city": "Gwenborough",
    "zipcode": "92998-3874"
  },
  "company": { "name": "Romaguera-Crona" }
}

Read the JSON like a form: "key": value pairs, nested objects in {…}, and (elsewhere) arrays in […]. The path to the city is address.city — that dot notation is exactly how your assertions will target values in the next lesson.

JSONPlaceholder is a free fake API made for practice — our target for this suite. For exploring real APIs at work you'll likely also use Postman (a GUI for requests); the concepts transfer 1:1.

Your testing brain, re-aimed: boundary analysis on ids (0? -1? 99999?), negative tests (wrong verb? malformed JSON?), state checks (does the GET reflect the POST?) — every technique you own applies verbatim to APIs.
⚠ when it breaks — the classics
PowerShell's curl behaves strangely
Invoke-WebRequest : A parameter cannot be found…

Fix: In PowerShell, curl is an alias for Invoke-WebRequest with different flags. Always type curl.exe — the real thing.

Could not resolve host
curl: (6) Could not resolve host: jsonplaceholder.typicode.com

Fix: A typo in the URL, or you're offline / behind a proxy. Paste the URL into a browser first — if the browser can't reach it, no tool can.

⚡ exercise · explore the API manually

Using curl.exe (or Postman if you prefer):

  1. GET /posts/1 — what fields does a post have?
  2. GET /posts/1/comments — an array. How many comments? (Count the { openers or scroll.)
  3. GET /posts/99999 — what comes back? (Empty {} — and status 404. Add -i to curl to see status: curl.exe -i …)
  4. Write down the JSON path to: a post's title; a comment's email.
key takeaways
  • APIs are the app without the UI: verbs + endpoints + JSON in/out + status codes.
  • 4xx = client-side problem, 5xx = server-side problem.
  • JSON paths (address.city) are how assertions will target values.
  • All your test design techniques apply to APIs unchanged.
← Back to roadmap Your first API test — REST Assured →