Computer Science Grade 10 20 min

4. HTTP Methods: GET, POST, PUT, DELETE

Introduce the different HTTP methods (GET, POST, PUT, DELETE) and their uses in API interactions.

Tutorial Preview

1

Introduction & Learning Objectives

Learning Objectives Differentiate between the GET, POST, PUT, and DELETE HTTP methods. Map the four main HTTP methods to the four CRUD (Create, Read, Update, Delete) database operations. Explain the concept of idempotency and identify which of the four methods are idempotent. Structure a conceptual API request, including the method, endpoint, and data payload for a given scenario. Identify the correct HTTP method to use for common web interactions like loading a profile, submitting a form, or deleting a comment. Analyze a simple API endpoint and predict the outcome of using different HTTP methods on it. Ever wonder how you post a photo to Instagram, and it just *appears* on your profile? 🤔 You're actually telling a server what to do using a secret language of the web!...
2

Key Concepts & Vocabulary

TermDefinitionExample HTTP (Hypertext Transfer Protocol)The set of rules for transferring files, such as text, images, sound, video, and other multimedia files, on the World Wide Web. It's the foundation of data communication for the web.When you type a URL into your browser, it uses HTTP to request the webpage from the server. API (Application Programming Interface)A set of rules and tools that allows different software applications to communicate with each other. It's like a menu at a restaurant that lets you order food from the kitchen without knowing how it's cooked.A weather app uses a weather service's API to request and display the current temperature. EndpointA specific URL where an API can be accessed. Each endpoint corresponds to a specific resource or set of...
3

Core Syntax & Patterns

CRUD Mapping POST -> Create | GET -> Read | PUT -> Update | DELETE -> Delete This is the fundamental pattern for interacting with data through an API. Each of the four main database operations (Create, Read, Update, Delete) maps directly to one of the four main HTTP methods. Use this to decide which method to use for any data-related task. Idempotency GET, PUT, and DELETE are idempotent. POST is not. An operation is idempotent if making the same request multiple times produces the same result as making it once. Fetching data (GET), updating a profile (PUT), or deleting a post (DELETE) multiple times has the same final effect. However, submitting a sign-up form (POST) multiple times will create multiple new accounts.

4 more steps in this tutorial

Sign up free to access the complete tutorial with worked examples and practice.

Sign Up Free to Continue

Sample Practice Questions

Challenging
A banking API has an endpoint `POST /api/accounts/A/transfer` with a body `{"to_account": "B", "amount": 100}`. If a network error causes this request to be sent twice, what is the most likely outcome, and how does this relate to idempotency?
A.$100 will be transferred once, because POST is idempotent.
B.The second request will fail with an error, because you cannot send the same POST request twice.
C.$200 will be transferred in total, because POST is not idempotent and each request creates a new 'transfer' resource.
D.$100 will be transferred, because the server will recognize it as a duplicate request and ignore it.
Challenging
An e-commerce API has an endpoint `/api/cart/items` for adding items to a shopping cart. The desired behavior is that if a user adds the same item multiple times, the quantity of that item in the cart increases. Which method is more appropriate for this 'add to cart' action and why?
A.PUT, because you are updating the state of the shopping cart resource.
B.POST, because it is not idempotent, and sending the same request multiple times should correctly result in multiple additions to the cart's state.
C.PUT, because it is idempotent, ensuring that adding the same item multiple times only results in one item in the cart.
D.POST, because GET cannot be used to modify data.
Challenging
An API for a to-do list has a single endpoint `/api/tasks`. The designer states all CRUD operations can be done on this endpoint. What is a major design flaw with this approach when using PUT or DELETE?
A.This design is perfect and is the most common way to build APIs.
B.PUT or DELETE request to `/api/tasks` is ambiguous; it doesn't specify *which* task to update or delete, and could dangerously affect all tasks.
C.The endpoint name is not descriptive enough; it should be `/api/to-do-list-tasks`.
D.You cannot use PUT and DELETE on the same endpoint; they require separate URLs.

Want to practice and check your answers?

Sign up to access all questions with instant feedback, explanations, and progress tracking.

Start Practicing Free

More from IV. Interacting with APIs: Data on Demand

Ready to find your learning gaps?

Take a free diagnostic test and get a personalized learning plan in minutes.