REST API Interview Questions for Freshers (2026) — with Answers
Updated August 2026
REST APIs are the one topic that shows up in almost every kind of fresher interview that involves a web application — backend, frontend, full-stack, and manual or automation QA alike. The reason is practical: whatever the role, the day job involves calling an endpoint, reading what comes back, and working out whose fault it is when the response is not what was expected. An interviewer can test all of that in ten minutes with three questions.
It is also a topic where freshers lose marks in a very specific way. Almost everyone can say that REST stands for Representational State Transfer and that GET fetches data. Far fewer can say what makes an API RESTful rather than merely reachable over HTTP, why 401 and 403 are different, whether DELETE is idempotent, or what they would actually check when handed an endpoint and asked to test it. Those are the questions that decide the round, and they are the ones this page is built around.
One note on scope. Authentication and security come up here at fresher depth — the concepts, the vocabulary, and the obvious mistakes — and that is what interviewers expect from a fresher. Do not overstate what you know about security in an interview; saying "I understand the flow at a high level, I have not implemented token validation myself" is a genuinely good answer, and it is far better than a confident description of something you would not be able to defend under one follow-up question.
Frequently asked questions
What is a REST API?
It is a way for two programs to talk to each other over HTTP, in which the things being worked with are modelled as resources that each have an address, and the ordinary HTTP methods say what you want done with them. REST — Representational State Transfer — is an architectural style rather than a protocol or a library: it is a set of conventions about how to use HTTP, not a piece of technology you install. So a client sends a request to a URL such as /api/students/42 with a method such as GET, and the server responds with a status code and usually a representation of that resource, typically as JSON. Say the definition, then immediately give that concrete example, because the example is what shows you have used one rather than read about one.
What actually makes an API RESTful?
This is the follow-up that separates candidates, because plenty of APIs are reachable over HTTP without being RESTful in any meaningful sense. At fresher depth, the constraints worth naming are these. Client-server: the two sides are separate and can change independently. Statelessness: every request carries everything needed to serve it, and the server keeps no memory of previous requests from that client. Cacheability: responses indicate whether they may be cached, so repeated reads need not hit the server. A uniform interface: resources have addresses, methods have consistent meanings, and responses are self-descriptive. And layered system: the client cannot tell whether it is talking to the origin server or to something in front of it, which is what makes load balancers and gateways possible. There is a sixth, code-on-demand, which is optional and rarely discussed. If you can add that a great many so-called REST APIs break the uniform interface — for instance by using POST for everything and putting the real verb in the URL, as in /api/getStudent — you have said something an interviewer will notice.
What does statelessness mean in REST, and does it mean the API cannot have users logged in?
It means the server does not retain client context between requests: each request is self-contained, and the server does not rely on a memory of what that client did previously to interpret it. It does not mean there is no such thing as a logged-in user. What it means is that the identity travels with each request — typically as a token in the Authorization header — rather than living in server-side session memory that a particular server instance holds. This is a favourite follow-up, so have the practical consequence ready: because any instance can serve any request, you can put ten identical servers behind a load balancer and it does not matter which one a request lands on. That is why statelessness is a scaling property rather than a piece of theory.
What is a resource, and how should endpoints be named?
A resource is the thing the API is about — a student, an order, an invoice — and each one has an address. The convention interviewers expect is nouns rather than verbs, plural collection names, and hierarchy expressed by path: /students for the collection, /students/42 for one student, /students/42/marks for that student's marks. The verb comes from the HTTP method rather than from the URL, which is why /getStudent, /createStudent and /deleteStudent are the classic non-RESTful smell — they duplicate in the path what the method already says. Other conventions worth naming: lowercase with hyphens rather than underscores or camelCase, no trailing slash, no file extensions, and versioning either in the path as /v1/students or in a header. None of this is enforced by anything; it is a convention, and consistency is the actual goal.
Which HTTP methods should you know, and what does each mean?
GET retrieves a resource and should not change anything. POST creates a new resource under a collection, or more loosely submits data for processing. PUT replaces a resource entirely with what you send. PATCH updates part of a resource. DELETE removes it. Two more are worth knowing because they get asked: HEAD is a GET without the response body, used to check existence or metadata cheaply, and OPTIONS asks what the server permits — which is what the browser uses for a CORS preflight. The mistake to avoid is describing these as if the HTTP specification enforced them. It does not: a server can perfectly well delete records inside a GET handler. The methods carry agreed meaning, and everything from browsers to caches to crawlers relies on that agreement, which is exactly why breaking it causes strange bugs.
POST versus PUT versus PATCH?
POST creates: you send it to a collection, as in POST /students, and the server decides the new resource's identifier and normally returns 201 with a Location header. PUT replaces: you send it to a specific resource, as in PUT /students/42, and the body is the complete new state of that resource — fields you leave out are meant to be cleared, not preserved, which is the part freshers get wrong. PATCH updates partially: PUT /students/42 with only the phone number would blank out the rest, whereas PATCH /students/42 with only the phone number changes just that. The other difference worth stating is idempotency: repeating the same PUT or PATCH leaves the resource in the same final state, while repeating a POST usually creates another record — which is precisely why a double-clicked submit button can create two orders.
What is idempotency, and which methods are idempotent?
An operation is idempotent if performing it several times leaves the system in the same state as performing it once. GET, PUT, DELETE, HEAD and OPTIONS are idempotent; POST is not; PATCH is not guaranteed to be, though it often is in practice, and saying that precisely is a good sign. The two traps are worth rehearsing. First, idempotent does not mean the response is identical every time — DELETE /students/42 might return 204 the first time and 404 afterwards, and it is still idempotent, because the state of the system is the same either way. Second, idempotency is a property of the effect, not of the code: a POST that the developer deliberately made safe to retry, using a request identifier the server remembers, is idempotent in practice. The reason interviewers care is retries — a client or a proxy can safely retry an idempotent request after a timeout, and cannot safely retry a POST.
What are safe methods?
A method is safe if it is not expected to change server state — GET, HEAD and OPTIONS. All safe methods are idempotent, but not the reverse: DELETE changes state, so it is idempotent without being safe. The practical consequence is what to talk about. Browsers, caches, link prefetchers and crawlers all assume GET is safe, so a GET endpoint that deletes or modifies something will eventually be triggered by something that was merely looking. The classic real-world version of this is an admin page with delete links implemented as GET, quietly wiped by a crawler or a browser prefetch.
Walk me through the parts of an HTTP request and response.
A request has four parts: the method, the target URL including any query string, a set of headers, and an optional body. GET and DELETE typically carry no body; POST, PUT and PATCH normally do. A response has three: a status line with the status code, headers, and usually a body. The headers are where freshers are thinnest, so know a handful properly. Content-Type says what the body is, commonly application/json. Accept says what the client would like back. Authorization carries credentials or a token. Cache-Control governs caching. Content-Length and Location come up too, the latter in a 201 response pointing at the newly created resource. If you can add that Content-Type describes the body you are sending while Accept describes what you want in return — a pair that gets mixed up constantly — that answers a follow-up before it is asked.
Path parameters versus query parameters versus request body — when do you use which?
A path parameter identifies a resource and is part of its address: /students/42, where 42 is which student. A query parameter modifies how a collection is returned rather than identifying one thing: /students?branch=cse&page=2&sort=name, so filtering, searching, sorting and pagination all belong there. The body carries the data for a create or an update, and is used with POST, PUT and PATCH rather than with GET. Two practical points worth adding. Query parameters end up in server logs, browser history and referrer headers, so credentials and tokens must never be put there — that is a genuine security question dressed up as a design question. And a GET with a body is technically possible but widely unsupported and treated as a mistake, which is why complex search endpoints sometimes use POST as a deliberate, documented compromise.
What are the HTTP status code families?
Five, and knowing the shape is more useful than memorising codes. 1xx informational, rare in day-to-day work. 2xx success — the request was understood and handled. 3xx redirection — the resource is somewhere else, or your cached copy is still valid, as with 304 Not Modified. 4xx client error — the request itself is wrong: bad syntax, missing authentication, no permission, no such resource. 5xx server error — the request was reasonable and the server failed. That 4xx-versus-5xx line is the one interviewers actually test, because it is the line that decides whose problem it is: a 4xx means fix your request, a 5xx means the server broke, and a server returning 500 for what is actually a validation error is sending the caller to debug the wrong thing.
200 versus 201 versus 204 — what is the difference?
200 OK is a generic success with a body, which is what a successful GET returns. 201 Created means a new resource was created, and it should come with a Location header pointing at it; that is the right response to a successful POST. 204 No Content means it succeeded and there is deliberately nothing in the body, which is the usual answer to a DELETE and sometimes to a PUT. There is also 202 Accepted, worth a mention: the request was accepted for processing that has not finished yet, which is how long-running jobs are handled. The failure this question is really probing is the API that returns 200 for everything, including errors, with a success flag hidden inside the JSON body — every generic client, cache and monitoring tool then reads those failures as successes.
400 versus 401 versus 403 versus 404 — when is each correct?
400 Bad Request means the request is malformed or fails validation — a missing required field, a string where a number belongs. 401 Unauthorized means the request is not authenticated: no credentials, or invalid or expired ones. Despite the name, it is about authentication, and the correct fix is to log in or refresh the token. 403 Forbidden means you are authenticated and the server knows exactly who you are, and you are still not allowed — a normal user hitting an admin endpoint. 404 Not Found means no such resource. The memorable version of the 401-versus-403 distinction is "who are you" versus "I know who you are and no". Two extra points that read as experience: 422 Unprocessable Entity is used by many APIs for semantic validation failures where 400 is reserved for malformed syntax, and some APIs deliberately return 404 instead of 403 to avoid revealing that a resource exists at all.
What do 405, 409 and 429 mean?
405 Method Not Allowed means the URL exists but that method is not supported on it — a POST to an endpoint that only serves GET — and a correct 405 includes an Allow header listing what is permitted. 409 Conflict means the request clashes with the current state, such as registering an email address that already exists, or updating a record that someone else has changed since you read it. 429 Too Many Requests is rate limiting, and it usually comes with a Retry-After header telling the client how long to wait. These three are worth knowing because they are exactly the codes a fresher defaults to calling 400, and because 429 in particular comes up the moment you use any third-party API.
What is the difference between 500, 502, 503 and 504?
500 Internal Server Error is the generic "something threw an exception and was not handled" — the application itself failed. 502 Bad Gateway means a server acting as a proxy got an invalid response from the server behind it. 503 Service Unavailable means the server is temporarily unable to handle the request, typically because it is overloaded or down for maintenance, and it may carry Retry-After. 504 Gateway Timeout means the proxy waited for the upstream server and gave up. The reason to know these apart is debugging: 500 sends you to the application logs, whereas 502, 503 and 504 point at the layer in front — a gateway, a load balancer, a container that is not up — which is a very different investigation. In a QA role, reporting "502 from the gateway" rather than "the site is down" is what makes a bug report useful.
What is the difference between authentication and authorization?
Authentication establishes who you are; authorization decides what you are allowed to do. Authentication comes first and is a single question with one answer; authorization is asked repeatedly, per action and per resource. The HTTP status codes mirror the split exactly — 401 for failed authentication, 403 for failed authorization — which is why this pair is so often asked alongside the status-code question. A clean fresher-level example: logging in with your credentials is authentication; the fact that you can see your own marks but not another student's is authorization. Note also the historical oddity worth mentioning if you want to sound precise: the header is called Authorization even though it carries authentication credentials.
What are the common ways an API authenticates a caller?
At fresher depth, four are enough. Basic authentication sends a username and password encoded in the Authorization header — encoded, not encrypted, so it depends entirely on HTTPS and is rare in modern APIs. An API key is a long secret string identifying the calling application rather than a user, sent in a header, and typical of third-party services. Bearer tokens, most commonly JWTs, are issued after login and sent as Authorization: Bearer <token> on each request, which is what makes stateless authentication possible. And OAuth 2.0 is the delegation framework behind "sign in with Google" — the flow by which one service gets limited access on your behalf without ever seeing your password. Say what each is for rather than claiming implementation depth, and if asked about JWT specifically, know that it has three parts — header, payload and signature — that the payload is encoded rather than encrypted, and therefore that putting anything secret in it is a mistake.
Where should a token go, and what should never go in a URL?
A token belongs in the Authorization header, as Bearer followed by the token. It should not go in the query string, and this is a question worth answering with the reasons rather than the rule: URLs are written into server access logs, kept in browser history, forwarded in the Referer header to third-party sites, and often cached by proxies — so a token in a URL leaks in four directions at once. The same applies to passwords, API keys and anything else secret. The related points an interviewer may look for: everything must be over HTTPS, since headers are only protected by transport encryption; tokens should have a short expiry with a refresh mechanism; and tokens must never be committed to a repository, which is one of the most common real-world leaks and something you may well be asked about because it happens to students constantly.
What is CORS and why does it block your requests?
CORS, Cross-Origin Resource Sharing, is a browser security mechanism. By default a browser stops JavaScript on one origin — scheme, host and port together — from reading responses from another, so a page served from localhost:3000 calling an API on localhost:8080 is blocked unless the API says it is allowed. The permission is granted by the server through response headers, principally Access-Control-Allow-Origin. For requests that are not simple, the browser first sends an OPTIONS preflight asking whether the actual request is permitted. Three things to add, because they are what the question is really testing. It is enforced by the browser, not by the server, which is why the same call works perfectly from Postman or curl and fails in the browser — the single most common confusion in a fresher's first project. It is not a defence against a malicious server, only against a page reading a response it should not. And the fix belongs on the server rather than in some browser flag, whatever the first search result suggests.
How do you handle pagination, filtering and sorting in a REST API?
All three through query parameters on the collection endpoint. Pagination is commonly offset-based — /students?page=2&limit=20 or ?offset=20&limit=20 — with the response carrying the total count and often links to the next and previous pages. Cursor-based pagination passes an opaque marker instead, and is worth naming as the approach that stays correct when records are being inserted while you page, since offsets shift underneath you. Filtering is ?branch=cse&year=2026 and sorting is ?sort=name or ?sort=-createdAt with a leading minus for descending. Two points that go beyond the syllabus: a collection endpoint should have a default limit so that an unpaginated call cannot pull a million rows, and pagination is a common source of test cases in QA — page zero, a page past the end, a limit of zero, a negative limit, a limit far above the maximum.
What is Postman and what do you actually use it for?
Postman is a client for calling APIs without writing a program — you set the method, the URL, headers, authentication and body, send the request, and read the status code, headers, response body and time taken. What to say beyond that, because everyone says that much. Collections group related requests, so a whole flow can be saved and rerun. Environments hold variables such as the base URL and the token, so the same collection runs against local, staging and production by switching one dropdown. Variables let a login request save its token and later requests use it automatically. The Tests tab holds small JavaScript assertions — checking the status code, a field in the response, the response time — which turns a collection into an automated regression suite, and that suite can then be run from the command line with Newman and wired into CI. If you have used any of that on a project, say so; a candidate who has scripted a token into an environment variable has clearly done more than take screenshots.
You are given an endpoint and asked to test it. What do you check?
This is the question that most often decides a QA fresher interview, and the marks are for having a structure rather than a list. Start with the happy path: a valid request returns the expected status code, the response body has the fields the contract promises with the right data types, and the values are correct. Then the negative cases: missing required fields, wrong data types, an invalid identifier, an identifier that does not exist, and a malformed body — each should return a sensible 4xx with a useful error message rather than a 500 or a stack trace. Then authentication and authorization: no token, an expired token, a malformed token, and a valid token belonging to a user who should not be allowed to see this resource. Then boundaries: empty strings, maximum lengths, zero, negative numbers, very large numbers, special characters and non-English text. Then the method itself: does an unsupported method return 405. And finally the non-functional checks: response time, the headers, and — the one freshers forget — whether the operation actually changed the database, since a 200 does not prove the record was written. Say that last one out loud; it is the difference between testing a response and testing a system.
How is API testing different from UI testing?
API testing exercises the layer beneath the interface, which changes both what you can find and how quickly you can find it. It is faster and far more stable, because there is nothing to render, no element locators to break, and no waiting for animations. It can reach cases the UI cannot produce — a field the form validates away, a combination the interface prevents, an error path the front end never triggers. It can begin before any UI exists, which matters when the front end and back end are built in parallel. And when a test fails, the failure is localised: a broken API test points at the service, whereas a broken UI test could be the service, the browser, the locator or the network. What it does not cover is everything the user actually experiences — layout, usability, accessibility, cross-browser rendering — which is why the two are complementary rather than alternatives. The framing interviewers like is the test pyramid: many fast API and unit tests underneath, and a small number of UI journeys on top.
An API call is failing. How do you debug it?
Work outwards from the request in a fixed order, and say the order out loud, because the method is what is being assessed. First read the status code, since it tells you which side to look at — a 4xx means the request is wrong, a 5xx means the server broke, and a connection error means you never reached it at all. Then inspect the actual request that was sent rather than the one you think you sent: the full URL, the method, the headers, whether Content-Type matches the body, and whether the body is valid JSON — a stray comma or a smart quote pasted from a document is a common culprit. Then check authentication: is the token present, correctly prefixed with Bearer, and unexpired. Then reproduce it outside the browser with Postman or curl, which immediately separates a CORS problem from a real failure. Then check the environment: right base URL, right port, is the service actually running. And if it is a 5xx, the answer is in the server logs, which is where a developer would go next. For a QA role, add that the reproduction steps, the exact request, the response body and the timestamp are what make the bug report actionable.
What is the difference between REST and SOAP, and where does GraphQL fit?
SOAP is a protocol with a strict specification: XML messages in a fixed envelope, a formal contract in a WSDL file, and built-in standards for security and transactions. It is verbose and rigid, which is exactly why it survives in banking, telecom and enterprise integrations where a strict contract is the point. REST is an architectural style rather than a protocol, usually JSON over HTTP, lighter and easier to consume, which is why it dominates web and mobile back ends. GraphQL is a different approach again: one endpoint, and the client sends a query describing precisely which fields it wants, which solves the over-fetching and under-fetching problems that come from fixed REST responses — at the cost of more complexity in caching, monitoring and rate limiting. You are not expected to have used SOAP or GraphQL as a fresher. Knowing what each is for, and being able to say that REST is the default for most new web APIs, is the full expected answer.
Is REST asked in the online tests for the 2027 batch, or only in interviews?
Both, in different forms. The technical MCQ sections at mass recruiters do carry HTTP and web-basics questions — which method is idempotent, what does 401 mean, which header carries the content type — so the recall version is genuinely tested and it is cheap marks. The interview is where the reasoning version comes out: why is that status code the right one, what would you test on this endpoint, why does it work in Postman and fail in the browser. If you are early in the 2027-batch cycle, do it in that order. Get the methods, the status codes and the header vocabulary solid enough for MCQs first, which is a couple of days. Then build one small project that calls a real API or exposes two or three endpoints of its own, because everything in the second category becomes much easier to answer once you have watched a request fail for a reason you had to find yourself.
How much REST is enough for the 2026-batch drives happening now?
For a developer role at a service company: the methods and what each is for, the status-code families with 200, 201, 204, 400, 401, 403, 404 and 500 cold, the parts of a request and response with the common headers, path versus query versus body, what statelessness means, token-based authentication at flow level, and why CORS blocks you. For a QA role: all of that, plus a structured answer to "what would you test on this endpoint", plus real familiarity with Postman including collections, environments and a couple of assertions in the Tests tab. Either way, the thing that lifts the answer above every other candidate is one worked example from something you built or tested yourself — an endpoint that returned 500 and why, a CORS error you fixed, a test that caught a wrong status code. Interviewers ask "have you used an API" expecting a yes or no, and the candidates who answer with a two-sentence story about one that broke are the ones who get remembered.
Don't just read REST APIs questions — get asked them
Phiny's AI interviews you on exactly these topics, follows up on weak answers, and tells you what a stronger answer looks like. Text interviews are free and unlimited.
Start a free AI mock interviewHow to prepare
- Learn the status codes as decisions, not as a table. 4xx means fix the request, 5xx means the server broke, 401 is "who are you", 403 is "I know who you are and no". An interviewer testing status codes is really testing whether you can work out whose fault a failure is.
- Rehearse the three pairs that get asked most: PUT versus PATCH, 401 versus 403, and authentication versus authorization. They are short answers, they are asked constantly, and fumbling one costs more than not knowing something advanced.
- Be exact about idempotency. GET, PUT, DELETE, HEAD and OPTIONS are idempotent, POST is not, and idempotent means the same end state rather than the same response — a second DELETE returning 404 is still idempotent. That last detail is a standard follow-up.
- Install Postman and actually use it on a free public API before the interview. Send a GET, then a POST with a JSON body, set an Authorization header, save a collection, put the base URL in an environment variable, and write one assertion in the Tests tab. That is one evening and it converts several answers from theory into experience.
- Have one story ready about an API call that failed and how you found the cause. A 500 you traced, a CORS error, a token you had forgotten to prefix with Bearer. Interviewers weight a real debugging story far above a correct definition.
- For QA interviews, prepare the "what would you test on this endpoint" answer as a structure you can recite: happy path, negative cases, authentication and authorization, boundaries, unsupported methods, then response time and whether the data actually changed. Candidates who list random cases sound junior; candidates with an order sound trained.
- Do not overstate your security knowledge. Explain the flow, name what you have not implemented yourself, and say the two things that matter — never put tokens in a URL, always use HTTPS. A calibrated answer survives follow-up questions that a confident one does not.
Where these questions get asked
- TCS NQT guide and Infosys hiring guide — the two biggest exams these questions appear in.
- All company placement guides — pattern, syllabus and rounds for every mass recruiter.