Interacting with an API requires a clear understanding of HTTP verbs. Each method has a specific purpose and semantic meaning.
1The Verbs of the Web
In a RESTful architecture, the URL identifies the 'resource' (e.g., /users), and the HTTP verb identifies the 'action'. GET is for reading, POST is for creating, PUT is for replacing, and DELETE is for removing. Adhering to these conventions makes your code more predictable and allows you to leverage standard browser and server behaviors, such as caching for GET requests.
2The Request Body
While GET and DELETE typically only require a URL, POST and PUT methods allow you to send a 'payload' or 'body'. Angular's HttpClient automatically serializes JavaScript objects into JSON for you. It also sets the correct headers, ensuring the server knows how to interpret the data you're sending. This automated serialization is one of the many ways Angular simplifies the developer experience.
3Step-by-Step Breakdown
Now that we have HttpClient injected, let's look at the four main methods you'll use to interact with data.
First is 'GET'. It retrieves data. It's the most common request. You just provide the URL and wait for the response.
Next is 'POST'. It sends new data to the server to create a resource. It requires a 'body' (the data you're sending).
Checkpoint: Which HTTP method is used to send new data to a server to create a record?
- →GET
- →POST
'PUT' is used to update existing data. You usually provide the ID of the item in the URL and the new data in the body.
Finally, 'DELETE'. It removes a resource. Like GET, it usually just needs the URL with the item's ID.
Checkpoint: When updating an entire user record with new data, which method is semantically correct?
- →PUT
- →DELETE
You've mastered the CRUD lifecycle! These four methods are the foundation of every data-driven Angular application.
Next, we'll learn how to handle cases where things go wrong: HTTP Errors.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Announce the Outcome of Every State-Changing Request (POST/PUT/DELETE)
After a successful `POST` or `DELETE`, sighted users typically see a visual confirmation (a toast, an item disappearing) — screen reader users need that same confirmation surfaced through an `aria-live` region, or they have no way of knowing the action actually succeeded.
2Confirm Destructive Actions Before Firing a DELETE Request
A `DELETE` triggered by a single accidental click (or keypress) with no confirmation step is both a UX and accessibility hazard — add an explicit, keyboard-reachable confirmation dialog before any irreversible request fires.
SEO Implications
- 1
REST API Calls Are Entirely Invisible to Search Engines
GET/POST/PUT/DELETE requests made via HttpClient execute purely client-side and carry no SEO weight directly — the only relevant concern is whether the data a GET request fetches ends up in server-rendered HTML that crawlers actually see.
- 2
Idempotent GET Requests Are Safe to Cache, Improving Perceived Performance
Because GET is semantically defined as safe and idempotent, caching GET responses (via an HTTP interceptor or service-level cache) is safe and can meaningfully reduce redundant network requests, improving perceived load speed on data-heavy pages.
Best Practices
Match HTTP Verbs to Their Semantic Meaning, Not Just Convention
Use `GET` only for retrieval with no side effects, `POST` for creation, `PUT`/`PATCH` for updates, and `DELETE` for removal — mixing these up (like using `GET` to trigger a state change) breaks caching assumptions and violates what other tools and proxies expect from each verb.
Handle Optimistic UI Updates Carefully With Rollback Logic
If you update the UI immediately before a `PUT`/`DELETE` request confirms success (for perceived speed), always include logic to roll back that UI change if the request ultimately fails — an optimistic update with no rollback path can leave the UI showing data that doesn't match the server.
Frequent Bugs
A `DELETE` request appears to succeed in the UI, but the item reappears after a page refresh.
This is a classic optimistic-update bug — the UI removed the item immediately without waiting for (or properly checking) the server's confirmation response, while the actual `DELETE` request failed silently. Ensure the request's success is verified before committing to the optimistic UI change, or roll back the change if it fails.
A `PUT` request meant to fully replace a resource unexpectedly wipes out fields the client didn't send.
This is the expected semantic behavior of `PUT` — it's defined as a full replacement of the resource, not a partial update. If only some fields should be updated, `PATCH` is the semantically correct verb to use instead.
Real-World Examples
Confirmed, Announced Delete Action
A task list item's delete button requires explicit confirmation before firing the DELETE request, and announces the outcome via an ARIA live region so all users know whether the deletion succeeded.
async deleteTask(id: number) {
if (!confirm('Delete this task?')) return;
await firstValueFrom(this.http.delete(`/api/tasks/${id}`));
this.announce('Task deleted.');
}