Without understanding REST APIs, you cannot pass the 200-901 exam, and more importantly, you cannot make two software programs talk to each other. This chapter explains the core language that every network device, cloud service, and automation tool uses to communicate: REST API principles, the five main HTTP methods, and the status codes that tell you if your request succeeded or failed. You will learn this not as dry theory, but as a practical toolkit you will use on every single IT job you ever have.
Jump to a section
A simple way to picture REST API Concepts and HTTP Methods
A busy restaurant kitchen. You are a customer sitting at a table, and the waiter is your only connection to the kitchen. You have a menu (the API documentation) that lists every dish the kitchen can prepare. You cannot walk into the kitchen yourself, so you must communicate all your requests through the waiter using a specific set of actions.
You start by asking the waiter for the menu (a GET request) to see what is available. You then decide you want a cheeseburger, no onions. You tell the waiter this, and they write it down on a ticket and hand it to the kitchen (a POST request to create a new order). The kitchen sends back a confirmation, including an order number (a unique ID for the resource). A few minutes later, you realise you actually do want onions after all. You call the waiter and say, ‘Please update order number 12 to include onions’ (a PUT or PATCH request to update an existing resource). Finally, when you are finished, you tell the waiter, ‘I am done with order number 12, please cancel it’ (a DELETE request).
The waiter does not care why you want the change; they just faithfully pass your request to the kitchen. The kitchen does not store your personal preferences between visits; each request is handled on its own merit (statelessness). The waiter uses standardised menus and order slips so that every waiter in every restaurant in the chain works the same way (uniform interface). This is exactly how a REST API works: a client sends standardised requests (HTTP methods) to a server, which performs the action and sends back a standardised response.
REST stands for Representational State Transfer. It is not a piece of software you download; it is a set of design rules for building web services. Imagine you have a spreadsheet of all your company's employees stored on a remote server. A REST API is the standardised way your computer asks the server, ‘Give me the list of employees’, ‘Add this new person’, ‘Update their phone number’, or ‘Remove them from the list’. The server does the work and sends back the result in a format both computers can understand, usually JSON (JavaScript Object Notation).
Every REST API has three main parts: the client, the server, and the resource. The client is your application or script. The server is the remote computer that holds the data. The resource is the specific piece of data you want to access, like a user, a product, or a network device config file. Each resource has a unique address called a URL (Uniform Resource Locator), for example: https://api.example.com/users/42.
The client sends an HTTP request to that URL. HTTP stands for HyperText Transfer Protocol, the foundation of data communication on the web. The request includes a method (the action you want to perform), headers (extra information like authentication tokens), and sometimes a body (the data you are sending). The server processes the request and sends back an HTTP response, which includes a status code (a three-digit number indicating success or failure), headers, and usually a body with the data you asked for.
There are five main HTTP methods you will use for 200-901:
GET: Retrieve data from the server. This is a read-only action. Asking the server for the list of employees does not change anything on the server. GET requests should never have a body.
POST: Create a new resource on the server. When you fill out a web form and click submit, that is often a POST request. You send data in the request body, and the server creates a new item and gives it an ID.
PUT: Replace an entire existing resource with new data. If you have a user profile with a name, email, and phone number, and you send a PUT request with only the name, the server may wipe the email and phone number fields because PUT replaces everything.
PATCH: Partially update an existing resource. If you only want to change the phone number without affecting the name or email, you use PATCH. PATCH only modifies the fields you send.
DELETE: Remove a resource from the server. Once you send a DELETE request, the resource is gone (or archived, depending on server logic).
REST APIs also rely on six key architectural principles. The most important for your exam are:
Statelessness: Each request from the client to the server must contain all the information the server needs to understand and process the request. The server does not store any client context between requests. If you are logged in, you must send your authentication token with every single request. This makes the system scalable and reliable.
Uniform Interface: Every REST API uses the same standardised way of talking. Resources are identified in URLs, you interact with them through standard HTTP methods, and data is exchanged in standard formats like JSON or XML (Extensible Markup Language). This means once you learn one REST API, you can quickly learn any other.
Client-Server Separation: The client and the server evolve independently. You can completely change the backend database without affecting the mobile app, as long as the API contract (the URLs, methods, and data formats) stays the same.
Cacheability: Responses from the server can be labelled as cacheable or non-cacheable. If a GET response says it can be cached, the client or an intermediary system can store the response and reuse it for identical future requests, saving time and bandwidth.
Layered System: The client does not need to know if it is talking directly to the server or to a proxy, a load balancer, or a cache. This allows for security layers and scaling without changing the client code.
Code on Demand (optional): The server can send executable code (like JavaScript) to the client to extend functionality. This is rarely used and not often tested.
HTTP status codes are the server's way of telling you whether your request worked. They are grouped into five categories:
1xx (Informational): The request was received and processing continues. You may see 100 Continue.
2xx (Success): The request was understood and accepted. The most common are 200 OK (general success), 201 Created (after a POST), and 204 No Content (success with no body, common for DELETE).
3xx (Redirection): Further action is needed to complete the request. 301 Moved Permanently tells the client to use a new URL from now on.
4xx (Client Error): The request was bad. 400 Bad Request (malformed syntax), 401 Unauthorized (you need to authenticate), 403 Forbidden (you are authenticated but not allowed), and 404 Not Found (the resource does not exist).
5xx (Server Error): The server failed to fulfil a valid request. 500 Internal Server Error is the most generic, meaning something broke on the server.
1. Identify the resource and its URL
Before you can interact with an API, you need to know the exact URL of the resource you want to work with. For example, if you want to fetch user number 42, the URL might be https://api.example.com/v2/users/42. This URL is called an endpoint. The base part (https://api.example.com/v2/) is the API's root, and the path (/users/42) identifies the specific resource.
2. Determine the correct HTTP method
Decide what action you want to perform: are you reading data (GET), creating something new (POST), replacing something entirely (PUT), applying a partial change (PATCH), or deleting (DELETE)? Choosing the wrong method is a common exam trap. For partial changes, always prefer PATCH over PUT.
3. Prepare the request headers
Headers carry important metadata. The most common headers are 'Authorization' (for API keys or tokens), 'Content-Type' (to tell the server the format of your data, e.g. application/json), and 'Accept' (to tell the server what format you want the response in). Without the correct headers, the server will return 401 Unauthorized or 400 Bad Request.
4. Construct the request body (if needed)
If you are using POST, PUT, or PATCH, you usually need to send data in the request body. This data is typically formatted as JSON. For example, a POST to create a new user might have a body like: {"name": "Alice", "email": "alice@example.com"}. The server will validate this data against its schema and return an error if fields are missing or wrong.
5. Send the request and receive the response
Your client (like a Python script, Postman, or a web browser) sends the HTTP request over the network to the server. The server processes it and sends back an HTTP response. The response contains a status code (e.g. 201 Created), response headers (e.g. setting a cookie or specifying the content type), and sometimes a response body with the server's data.
6. Parse the status code and handle errors
Your script must check the status code immediately. If it is a 2xx code, proceed to use the response body. If it is a 4xx code, your client made a mistake (bad data, wrong method, missing auth). If it is a 5xx code, the server is broken or overloaded. Implement retry logic for 5xx errors and log 4xx errors for debugging.
7. Extract and use the response data
If the request succeeded, the response body will contain the data you requested (for GET) or the newly created resource (for POST). Parse the JSON (or XML) and use the data in your application. For example, extract the new user ID from a POST response and store it for future updates or deletions.
An IT professional at a mid-sized company needs to automate the onboarding of new employees. Every time someone new joins, the HR system (which is a cloud-based SaaS product) must create a user account in the company's network device management system (a separate on-premise application). Doing this manually takes 30 minutes per employee and is prone to typos. The IT professional decides to write a Python script that uses REST APIs to automate the process.
First, the IT professional reads the API documentation for the network device management system. The documentation tells them the base URL is https://netmgmt.company.local/api/v2, and the resource for users is at /users. To create a user, they must send a POST request to https://netmgmt.company.local/api/v2/users with a JSON body containing the new user's first name, last name, department, and role.
Here is the step-by-step scenario:
The script receives a notification from the HR system that a new employee named Alice Smith has been added. The script extracts her details: first name Alice, last name Smith, department Engineering, role Junior Developer.
2. The script constructs a JSON body: { "firstName": "Alice", "lastName": "Smith", "dept": "Engineering", "role": "Junior Developer" }
The script sends an HTTP POST request to https://netmgmt.company.local/api/v2/users. It includes an Authorization header containing an API key (a secret token that proves the script is allowed to access the API).
The server validates the API key. If the key is missing or invalid, the server sends back a 401 Unauthorized status code. The script must handle this error by logging the failure and alerting the IT team.
If the key is valid, the server checks the data. If the JSON body is malformed (for example, if the script sends "firstname" instead of "firstName"), the server sends back 400 Bad Request. The script must parse this error and fix the field name.
If everything is correct, the server creates the user account and sends back a 201 Created status code. The response body includes the new user's unique ID, for example: { "id": 1234, "status": "active" }.
The script then needs to add Alice's new user ID to a group called 'Engineering-Users' to grant network access. The script sends a PUT request to https://netmgmt.company.local/api/v2/groups/Engineering-Users/members with the user ID in the body. This replaces the entire member list of the group with only Alice — which is wrong if there are other members. The IT professional should instead use PATCH to append Alice to the existing member list.
When Alice eventually leaves the company, the script will send a DELETE request to https://netmgmt.company.local/api/v2/users/1234. The server responds with 204 No Content to indicate the deletion succeeded but no data is returned.
The IT professional also implements error handling. If the server is temporarily down and returns 500 Internal Server Error, the script waits 30 seconds and retries up to three times. If the server returns 429 Too Many Requests (rate limiting), the script waits longer. This real-world automation is exactly what the 200-901 exam expects you to understand: how to use HTTP methods correctly, interpret status codes, and design a reliable integration.
The 200-901 exam loves to test your knowledge of REST API concepts through scenario-based multiple-choice questions and drag-and-drop exercises. You will not be asked to write code, but you must be able to identify the correct HTTP method for a given task, the correct status code for a given outcome, and the correct REST principle violated in a scenario.
Here are the exact topics the exam tests:
Identifying the HTTP method: The exam will describe a scenario like 'An application needs to update only the phone number of an existing user' and give you four options: GET, POST, PUT, PATCH, DELETE. Many candidates incorrectly choose PUT because they think 'update' always means PUT. The trap is that PUT replaces the entire resource; PATCH is for partial updates. Memorise: PUT = full replacement, PATCH = partial modification.
Matching status codes to outcomes: You will see a status code and be asked what it means, or you will see an outcome (like 'the server cannot find the requested resource') and be asked for the correct code (404). The trap codes are 401 vs 403: 401 means you are not authenticated (you haven't logged in), 403 means you are authenticated but not authorised (you don't have permission).
REST principles: The exam loves statelessness and the uniform interface. A typical trap question: 'An API requires the client to send a session ID with every request, and the server stores the client's state between requests. Which REST principle does this violate?' The answer is statelessness. Another trap: 'The API returns data in HTML format and requires the client to know the server's internal folder structure to build URLs. Which principle is broken?' The answer is the uniform interface.
Idempotency: A key concept the exam tests indirectly. An idempotent method means sending the same request multiple times produces the same result as sending it once. GET, PUT, DELETE are idempotent. POST is not — if you send the same POST twice, you will likely create two duplicate resources.
CRUD mapping: The exam expects you to know that CRUD (Create, Read, Update, Delete) maps directly to HTTP methods: Create = POST, Read = GET, Update = PUT/PATCH, Delete = DELETE.
Request and response structure: The exam may ask which part of an HTTP request contains the data being sent to the server: the body. Or which part contains metadata like authentication: the headers.
Common trap patterns: They will give you a status code like 200 OK for a POST request. Is that correct? No — 201 Created is the standard success code for POST. They will give you 204 No Content for a GET request. Is that correct? Yes, if the resource exists but is empty. They will give you a scenario where a client sends a DELETE request and the server responds with 200 OK and a body containing the deleted resource. Is that valid? Yes, some APIs do return the deleted resource, but the standard is 204 No Content. The exam may penalise you for choosing 204 if the scenario explicitly says the server returns the deleted item.
Quizlet-style memorisation: Learn these codes by heart: 200 OK, 201 Created, 204 No Content, 301 Moved Permanently, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method Not Allowed, 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable.
REST is not software; it is a set of design rules for building web services that use standard HTTP methods, status codes, and URLs.
The five main HTTP methods are GET (read), POST (create), PUT (full replace), PATCH (partial update), and DELETE (remove).
PUT replaces an entire resource; PATCH modifies only the fields you send — this distinction is a common exam trap.
Statelessness means every HTTP request must contain all the information the server needs; the server never stores client state between requests.
A 401 Unauthorized status code means you are not authenticated (no valid login); a 403 Forbidden means you are authenticated but not permitted to access the resource.
A 201 Created status code is the standard success response for a POST request that creates a new resource, not 200 OK.
HTTP methods like GET, PUT, and DELETE are idempotent — sending the same request multiple times has the same effect as sending it once; POST is not idempotent.
The base URL and endpoints (specific resource paths) together form the API's address, and every resource is identified by a unique URL.
These come up on the exam all the time. Here's how to tell them apart.
PUT
Replaces the entire resource with the data you send.
If you omit a field, that field is deleted or reset to default.
Used when you are sending a complete representation of the resource.
PATCH
Modifies only the fields you send; other fields stay unchanged.
Omitting a field means 'do not change this field'.
Used when you are sending only the fields that need updating.
401 Unauthorized
You have not provided any valid authentication credentials.
The server does not know who you are.
The solution is to provide a valid API key or login.
403 Forbidden
You are authenticated (the server knows who you are) but you lack permission.
The server knows you are logged in as a standard user, but you tried to access admin-only data.
The solution is to request higher-level permissions or use a different account.
Stateless API
The server does not store any session or client context between requests.
Every request must contain all data the server needs to understand it.
Easier to scale horizontally (add more servers) because any server can handle any request.
Stateful API
The server stores session data, like a shopping cart or login state.
The server remembers previous requests and can use that context.
Harder to scale because the same server must handle all requests from the same client.
GET
Reads data from the server. Never creates or changes anything.
Idempotent: sending the same GET 10 times gets the same result.
The request has no body.
POST
Creates a new resource or triggers an action on the server.
Not idempotent: sending the same POST 10 times may create 10 resources.
The request typically has a body containing the new data to create.
Mistake
PUT and PATCH are interchangeable because both update data.
Correct
PUT replaces the entire resource. PATCH applies a partial update to only the fields you send.
Beginners see 'update' as a single concept and do not read API documentation carefully. The exam deliberately tests the distinction.
Mistake
401 Unauthorized means you are not allowed to access the resource.
Correct
401 means you are not authenticated (no valid credentials). 403 Forbidden means you are authenticated but not authorised to access the resource.
The word 'unauthorized' in the status code name is misleading. English speakers naturally interpret it as 'not allowed', but HTTP uses it for 'not authenticated'.
Mistake
A POST request always creates a new resource, and a GET request never changes anything.
Correct
POST can also be used to perform an action that is not strictly creating a resource, like submitting a search query. GET should be safe and read-only, but poorly designed APIs may use GET to trigger actions.
The exam teaches the ideal RESTful behaviour, but real-world APIs sometimes violate these rules. Beginners memorise the ideal and are confused by counterexamples in practice.
Mistake
If I send a DELETE request and get back 200 OK, the server is doing it wrong.
Correct
200 OK with a deleted resource in the body is technically valid, though 204 No Content is more common. The exam expects you to know both are acceptable but 204 is standard.
Candidates learn rigid rules (DELETE = 204), but REST does not enforce strict code usage. The exam tests your knowledge of the standard but also your ability to accept variation.
Mistake
A REST API communicates over a private, secure proprietary protocol, not HTTP.
Correct
REST APIs use standard HTTP and HTTPS (HTTP Secure). They work over the same protocol that powers web browsing.
The word 'API' sounds technical and intimidating, leading beginners to assume it uses exotic protocols. They do not realise they already use HTTPS every time they visit a website.
Mistake
The server must always return the requested data in the response body, even for a 400 or 500 error.
Correct
Error responses may or may not include a body. The client should check the status code first, and only then parse the body for a detailed error message if one exists.
Beginners expect every response to contain useful data, not realising that a 400 error body might be empty or just a simple string like 'Bad request'.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A regular website returns HTML pages meant for humans to read in a browser. A REST API returns raw data (usually JSON) meant for other computer programs to consume. Both use HTTP, but the purpose and the format are different.
Technically yes, but it is against REST API best practices. Using POST for updates makes the API confusing and breaks the principle of using the correct HTTP method for clear intent. The 200-901 exam expects you to use the correct method.
Most servers will ignore the body or return a 400 Bad Request. The HTTP specification says GET requests should not have a body. If you need to send data to filter results, use query parameters in the URL instead (e.g. /users?status=active).
No, but you must memorise the most common ones: 200, 201, 204, 301, 400, 401, 403, 404, 405, 500, 502, 503. The exam will test these specifically, not obscure ones like 418 I'm a teapot.
An idempotent HTTP method means sending the same request multiple times produces the same outcome as sending it once. For example, DELETE is idempotent: deleting user 42 once or three times results in user 42 being deleted. POST is not idempotent: creating the same user twice creates two different users.
Since the server does not store login state, the client must send authentication credentials (like an API key or a JSON Web Token) in the header of every single HTTP request. The server validates the credentials on each request independently.
You've finished REST API Concepts and HTTP Methods. Continue through the 200-901 study guide to build a complete picture of the exam.
Done with this chapter?