¶ REST API
¶ 1. Why you should care
REST (REpresentational State Transfer) is the de-facto style for web services: roughly 8 out of 10 public APIs you’ll meet follow it, so mastering the basics lets you speak to almost any modern backend.(Integrate.io)
¶ 2. REST in 60 seconds
A REST API exposes resources (nouns such as /users/42) over plain HTTP. Clients use standard verbs to act on those resources:
| Verb | Typical intent | Idempotent? |
|---|---|---|
| GET | Read | ✔︎ |
| POST | Create / adj. action | ✖︎ |
| PUT | Replace | ✔︎ |
| PATCH | Partial update | ✖︎ |
| DELETE | Remove | ✔︎ |
RESTful servers must also follow six architectural constraints (uniform interface, client-server, stateless, cacheable, layered, code on demand optional).(restfulapi.net, Integrate.io)
¶ 3. Common response codes
- 200 OK / 201 Created – success
- 400 Bad Request – client error (malformed JSON, missing fields)
- 401/403 Unauthorized / Forbidden – auth problems
- 404 Not Found – wrong URI or missing record
- 500+ Server errors – bug, outage, etc.(Postman Blog)
¶ 4. Tiny “Hello World” example
GET https://api.example.com/items/123
Accept: application/json
Typical JSON reply:
{
"id": 123,
"name": "Widget",
"price": 9.99
}
¶ 5. Trying REST in Divooka
Divooka lets you build the call as a node graph instead of filling long forms:
- Send (HTTP) Request node – set GET and URL
{{baseUrl}}/items/{{itemId}}. - Headers – drop a Custom Header node for key:value pairs like
Accept: application/json. - (Optional) Auth node – choose Basic, Bearer, or OAuth 2.0.
- Preview JSON node to parse JSON payloads – pretty-prints and type-checks the body.
Everything is visual and reusable: connect the same response into further logic (save to DB, update UI, trigger another request) without writing glue code.
You can view more practical examples on the Web API Testing page.
¶ Environment variables
Define baseUrl, apiKey, or authToken once in Environments and reference them anywhere with Get Environment Variable nodes. Switch environments (dev/staging/prod) using Switch node.
¶ Saving & Sharing
Save and group related requests into graphs as documents, so it can be easily reused and shared.
¶ 6. Best-practice checklist
For designing your own REST APIs:
- Keep URIs noun-based (
/orders/17, not/getOrder). - Use correct verbs (no
GET /deleteUser). - Surface pagination & filtering (
?page=2&limit=50). - Version in the path or header (
/v1/), never break existing clients. - Secure with HTTPS, auth, and sensible rate limits.
- Document with OpenAPI; Divooka can import the spec and scaffold nodes automatically.(idratherbewriting.com)
¶ 7. Further reading
- Hunger for more? Check out our in-depth discussion on the topic of HTTP, Methods & Web API.
- Usage documentation in Divooka.
- Roy Fielding’s REST dissertation (the original source)
- RFC 9110 – HTTP Semantics
- Postman “REST API examples” blog for real-world patterns(Postman Blog)
- Divooka Wiki → App Development > API Testing (deep-dive on every node and feature)
With these essentials you can explore any REST endpoint confidently - and wire it into your Divooka flows to suit your application needs.