REST API Endpoints Explained (With Real Examples)

Developers throw around "API," "endpoint," and "route" as if they're interchangeable — and that fuzziness makes it harder to design good systems or explain them to a junior engineer. This article gives you a precise mental model for REST API endpoints, then makes it concrete with a working example: a headless browser rendering API that turns URLs into screenshots, PDFs, and structured data.

What Is a REST API Endpoint?

A REST API endpoint is a specific URL that represents a resource, paired with an HTTP method that tells the server what to do with it. That's the whole definition. POST https://api.example.com/screenshot is an endpoint. So is GET https://api.example.com/jobs/123.

Here's the distinction developers often blur:

• API — the overall contract: the full set of endpoints, auth rules, and data formats a service exposes.
• Endpoint — one specific URL + method combination within that API, representing one resource or action.
• Route — the internal server-side mapping (in your framework's code) that matches an incoming request to the function that handles it. Routes are implementation detail; endpoints are the public interface.

So the short answer is: an endpoint is the address plus the verb. REST (Representational State Transfer) is the architectural style that governs how those addresses and verbs should behave — resources are nouns, state is transferred as data (usually JSON), and each request is self-contained, without the server remembering previous ones.

The Anatomy of a Well-Designed Endpoint

Every REST API endpoint you'll ever call or design breaks down into the same six parts. Understanding this structure is what lets you evaluate a third-party API before you integrate it.

Component	Purpose	Example
Base URL	Root address of the API	https://api.browsevra.com
Resource path	What you're acting on	/v1/screenshot
HTTP method	The action being performed	POST
Headers	Auth, content type, metadata	Authorization: Bearer
Body / query params	Input data	{ "url": "https://example.com" }
Response	Status code + JSON payload	200 + { "image_url": "..." }

REST endpoints map cleanly to CRUD-style actions. GET retrieves a resource without side effects. POST creates something new or triggers an action (like rendering a page). PUT replaces a resource entirely. PATCH updates part of it. DELETE removes it. A rendering API leans heavily on POST because generating a screenshot or PDF is an action with a result, not a static resource fetched by ID — though a well-designed API often exposes a GET /jobs/{id} endpoint to check on an async render.

Authentication headers deserve specific mention: a well-behaved endpoint expects credentials in the Authorization header (Bearer ) rather than buried in the query string, where they can leak into logs and browser history. If an API's only auth option is ?api_key=... in the URL, that's a signal to check its security posture before sending it production traffic.

A Real Example: Endpoints for Headless Browser Rendering

Abstract definitions only click once you see them applied. Browsevra runs managed headless browsers behind a small set of REST endpoints, each mapped to a rendering task:

POST /screenshot — Renders a URL in headless Chromium and returns an image.

POST /v1/screenshot
Authorization: Bearer sk_live_xxx
Content-Type: application/json

{ "url": "https://example.com", "format": "png", "fullPage": true }

Response:

{ "status": "success", "image_url": "https://cdn.browsevra.com/img/abc123.png" }

POST /pdf — Same input shape, different output: a print-ready PDF instead of an image. Useful for invoices, reports, or archiving rendered pages.

POST /render — Returns the fully rendered HTML after JavaScript execution, for pages that build their content client-side.

POST /extract — Accepts a URL (and often selectors) and returns structured JSON pulled from the rendered DOM, rather than an image or raw markup.

Notice the pattern: every path is a noun (/screenshot, /pdf, /extract), every call is POST because it triggers real browser work, and every response follows the same envelope — a status field plus a predictable payload. That consistency is what separates a well-designed API from one you'll spend hours debugging. For a deeper look at one of these in production, see Open Graph Image Generation API: A Production Pattern and the companion piece on Structured Data Extraction API: A Framework for Tables.

REST API Endpoint Best Practices

A few conventions separate endpoints that are pleasant to integrate from ones that generate support tickets:

• Use nouns, not verbs, in paths. /screenshot beats /takeScreenshot. The HTTP method already supplies the verb.
• Version your API. A /v1/ prefix lets you evolve the contract without breaking existing integrations.
• Return meaningful status codes. 200 for success, 401 for missing/invalid auth, 429 when a client hits a rate limit, 500 for an unexpected server failure. Guessing at status codes forces every caller to parse response bodies just to know if something worked.
• Design for rate limits. A serious API returns 429 with a Retry-After header rather than silently dropping requests; clients should implement exponential backoff.
• Keep responses predictable. Same shape on success, same shape on error, every time — no endpoints that sometimes return an array and sometimes an object.
• Authenticate with API keys or bearer tokens, never with credentials embedded in the path.

These aren't stylistic preferences — they're what let you trust a new API quickly. The full parameter reference, schemas, and auth flows for each Browsevra endpoint live in the Docs, which is the fastest way to check whether an endpoint follows these rules before you build against it.

Calling an Endpoint: A Minimal Example

Here's the entire loop — request in, JSON out — in curl:

curl -X POST https://api.browsevra.com/v1/screenshot \
  -H "Authorization: Bearer sk_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com", "format": "png"}'

And the same call in JavaScript with fetch:

const res = await fetch("https://api.browsevra.com/v1/screenshot", {
  method: "POST",
  headers: {
    "Authorization": "Bearer sk_live_xxx",
    "Content-Type": "application/json"
  },
  body: JSON.stringify({ url: "https://example.com", format: "png" })
});
const data = await res.json();
console.log(data.image_url);

That's a complete REST API endpoint interaction: method, headers, body, and a parsed response — no SDK required.

Frequently Asked Questions

What's the difference between an API and an API endpoint?

An API is the entire interface a service exposes — every resource, auth rule, and data format it supports. An endpoint is one specific URL-and-method pair within that API, like POST /screenshot. Think of the API as the whole address book and an endpoint as a single entry in it.

How many endpoints does a typical REST API have?

It varies widely, from a handful to hundreds, depending on how many resources and actions the service exposes. A focused API like a rendering service might need only four or five core endpoints (screenshot, PDF, render, extract, job status), while a large platform API can expose dozens tied to different resource types.

Is REST still the standard, or should I use GraphQL instead?

REST remains the dominant standard for public APIs because it's simple, cacheable, and maps naturally to HTTP semantics. GraphQL suits cases with complex, nested data requirements and many client-specific queries, but for action-oriented services like rendering or file generation, REST endpoints are simpler to design, document, and debug.

How do I authenticate requests to a REST API endpoint?

Most modern REST APIs use an API key or bearer token sent in the Authorization header, formatted as Authorization: Bearer . Avoid APIs that only support keys in the query string, since URLs are logged more often than headers and that increases the risk of credential leakage.

What status code should an endpoint return if a request is malformed?

A malformed request should return 400 Bad Request, distinct from 401 (missing/invalid auth) or 422 (semantically invalid but well-formed data). Returning 200 with an error buried in the body forces every client to parse successful-looking responses just to detect failure, which is a common design mistake.

Can a single endpoint handle multiple HTTP methods?

Yes — the same path can support different methods for different actions on the same resource, such as GET /jobs/{id} to check status and DELETE /jobs/{id} to cancel it. This is standard REST design: the path identifies the resource, and the method defines the operation performed on it.

Reading about endpoints only gets you so far — the fastest way to understand a well-designed REST API is to call one. Browse the full endpoint reference in the Docs, then check Pricing to run a free screenshot, PDF, or HTML render call against browsevra yourself.