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 →