What Is a REST API Endpoint?

A REST API endpoint is a specific URL where an API exposes one resource, paired with an HTTP method that says what to do with it. GET /posts/123 and DELETE /posts/123 are two different operations on the same endpoint's resource, not two different endpoints. The URL names the thing; the method names the action.

That resource-per-URL model is REST's defining trait. It's the opposite of GraphQL's single-endpoint approach, where one URL handles every operation and the query body decides the rest.

What Makes a URL an "Endpoint"?

An endpoint is the combination of a URL path and an HTTP method, not the path alone. /posts with GET lists posts. /posts with POST creates one. Same path, different endpoint, different behavior.

GET    /posts          → list posts
POST   /posts          → create a post
GET    /posts/123      → get one post
PATCH  /posts/123       → update one post
DELETE /posts/123      → delete one post

That table is the whole shape of a well-designed REST resource: one path pattern, five methods, predictable behavior at each intersection.

The HTTP Methods That Define Endpoint Behavior

GET reads and never changes server state, which is what makes it safe to cache and safe to retry automatically. POST creates a new resource, and calling it twice usually creates two of them, not an update. PUT replaces a resource entirely; PATCH updates part of it. DELETE removes it.

// Draftbase's delivery API: one resource, standard REST verbs
const res = await fetch('https://api.draftbase.co/delivery/entries/123', {
  headers: { Authorization: `Bearer ${process.env.DRAFTBASE_KEY}` },
});

Getting the method wrong is a real bug, not a style choice. A GET that secretly mutates data breaks browser prefetching. It breaks retries too, and any cache sitting in front of your API, since all three assume GET is safe by contract.

What's in an Endpoint's URL Structure?

A resource-oriented URL names a noun, not a verb: /posts, not /getPosts. The method already carries the verb, so repeating it in the path is redundant and it's also the single most common REST design mistake in real APIs.

Nesting shows a relationship. /posts/123/comments reads as "comments belonging to post 123," clearer than a flat /comments?postId=123. Both work, though. Query parameters still handle filtering, sorting, and pagination on top of the resource path (/posts?limit=20&sort=recent).

Path parameters vs query parameters

A path parameter identifies which resource: /posts/123, the 123 names one specific post. A query parameter modifies how you get it: /posts?status=published, filtering the collection. Mixing the two up, stuffing an identifier into a query string, works but reads as an accident, not a design choice.

What Does a REST Endpoint's Response Look Like?

A REST endpoint's response shape is fixed at the API's design time. GET /posts/123 always returns the same fields for a post, whether the caller needs all of them or one. That's the tradeoff GraphQL exists to solve: letting the caller pick fields instead of the server dictating them. For a simple resource, though, a fixed shape is a feature. Predictable, cacheable, easy to document once.

{
  "id": "123",
  "title": "Launch week",
  "slug": "launch-week",
  "publishedAt": "2026-08-20T13:19:00.000Z"
}

Status codes carry meaning too: 200 for success, 201 for a resource just created, 404 for a resource that doesn't exist, 429 for rate-limited. A client can branch on the status code alone, before even parsing the body.

What Makes an Endpoint Well-Designed vs Poorly Designed?

A well-designed endpoint set is consistent. Every resource follows the same pattern: plural nouns (/posts, not /post), the same pagination params on every list endpoint, the same error shape on every failure. Consistency is what lets a developer guess the next endpoint correctly without checking the docs.

A poorly designed set breaks that pattern resource by resource. One endpoint paginates with ?page=2, another with ?offset=40. One error response is { "error": "..." }, another is { "message": "..." }. Each inconsistency is small. Together, they mean every new integration starts by re-reading the docs instead of guessing from a pattern that already held.

Consistent (good):
GET /posts?limit=20&after=abc123
GET /entries?limit=20&after=xyz789

Inconsistent (bad):
GET /posts?page=2&size=20
GET /entries?offset=40&count=20

Do REST Endpoints Need Versioning?

Usually, yes, once a breaking change is coming. /v1/posts and /v2/posts let old clients keep working against /v1 while new clients move to /v2, instead of a breaking change landing on every caller at once with no warning.

Versioning in the URL path is the most common approach, though some APIs version through a header instead. Either works. What matters is picking one and applying it consistently, not mixing both across different resources.

The Underused Angle

Most "what is a REST endpoint" explainers describe the URL-and-method model and stop, treating REST as purely a syntax convention. The part that actually gets APIs into production trouble is idempotency, whether calling an endpoint twice with the same input produces the same result as calling it once.

GET, PUT, and DELETE are supposed to be idempotent by the HTTP spec: retry-safe. POST isn't, by design, which is exactly why a flaky network connection retrying a POST /orders call can create a duplicate order. That's not a REST design failure; it's the spec working as intended. The fix belongs at the client, an idempotency key sent with the request, not in blaming the method for doing what it was always defined to do.

How Is This Different from a GraphQL Endpoint?

A GraphQL API typically exposes one URL, /graphql, for every operation. The query body, not the URL or method, decides what data comes back and what changes. REST spreads that same surface across many URLs, one per resource, with the method carrying the intent.

Neither model is strictly better. REST's fixed shapes cache well at the HTTP layer and stay simple to document. GraphQL's single endpoint avoids over-fetching and under-fetching when a frontend's data needs vary by page. See the full REST vs GraphQL comparison for the tradeoffs in more depth.

Conclusion

A REST API endpoint is a URL-plus-method pair, one path per resource, with GET/POST/PUT/PATCH/DELETE carrying the intent the path doesn't. Idempotency, not just URL naming, is what separates an endpoint design that survives retries from one that silently duplicates data under real network conditions. Building content endpoints from scratch? Draftbase's delivery API ships REST resources with predictable shapes, cursor pagination, and status codes that follow the spec. No reinventing this from a blank route file.