Backend Interview: Why Must 405 Method Not Allowed Return Allow?

Question

You maintain a file API: GET /v1/files/:id reads a file, but a client sends POST or DELETE to the same resource. The interviewer asks you to design the response and explain the difference between 405, 404, 403, OPTIONS, and CORS preflight. Cover route matching, the Allow header, the error body, tests, and rollout.

Context and constraints

• The resource route matches a concrete file, but only GET and HEAD are enabled today.
• An SDK version mismatch may cause an invalid method, and a proxy may rewrite or intercept it.
• Callers need a diagnosable response, while disabled methods must not be advertised as available.
• If resource existence is sensitive, the team may use a consistent 404 hiding policy, documented in the API contract.

What the interviewer is testing

Separate resource matching from method dispatch

Match host, path, version, and resource identifier first, then look up the resource's allowed method set. Return 404 when the path is absent; return 405 when the path exists but the method is outside that set. Authorization still follows the security policy: an authenticated caller without permission may receive 403. Do not turn every authorization failure into 405.

405 must include Allow

405 means the server recognizes the request method but the target resource does not support it. The response must include Allow, listing methods currently supported by that resource, for example:

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, OPTIONS
Content-Type: application/problem+json

{"type":"about:blank","title":"Method Not Allowed","status":405,"detail":"Use one of the methods listed in Allow."}

Allow describes resource capability. It is different from CORS's Access-Control-Allow-Methods, which participates in browser cross-origin policy and cannot replace the HTTP method contract expressed by 405.

Model OPTIONS separately

OPTIONS can ask about communication options. A browser CORS preflight also sends Origin and Access-Control-Request-Method. Whether preflight succeeds depends on CORS response headers and authentication policy. Do not turn every OPTIONS request into 405, and do not treat Allow as a CORS authorization list.

Clarifying questions before answering

• Does the resource actually exist? If not, use 404; if a security policy hides existence, confirm whether it consistently returns 404.
• Can allowed methods vary by tenant, resource state, or API version? The answer changes the context used to generate Allow and the cache key.
• Will the gateway rewrite unknown methods, and who owns Allow generation? The answer defines the debugging boundary and the single source of truth.

30-second answer framework

“The path matched, but the method is outside the resource's capability set, so I return 405 and list the methods that are truly supported in Allow. A missing path is 404, an authorization denial follows the 403 policy, and OPTIONS plus CORS preflight use separate headers. I would finish with a method matrix, a real gateway-path test, and rollout metrics.”

Step-by-step deep answer

Define each resource route's allowed methods in an auditable registry, then let the router use that same registry for dispatch and Allow generation. For POST /v1/files/123, return 405 if the resource exists and POST is not registered; return 404 if 123 does not exist; return 403 for a matched request denied by authorization policy. HEAD often follows the readable capability of GET, but the framework's actual behavior is the source of truth.

The error body should provide a stable status, title, and actionable explanation without exposing stack traces or internal route details. List only methods that are actually enabled in Allow; during a rollout, do not advertise write capabilities that are not deployed. If the security policy hides resource existence, document its 404-versus-405 choice, log fields, and client retry behavior.

High-quality sample answer

“I would first let the router establish whether the file exists, then dispatch from one method registry. For an existing file receiving an unregistered POST, return 405 and put GET, HEAD, plus a genuinely supported OPTIONS, in Allow; return 404 for a missing file and follow the authorization policy for 403. CORS preflight uses Access-Control-Allow-Methods, not Allow. The gateway and application get one owner for header generation. Contract tests check every status and method set, while rollout monitors 405 by method.”

Common errors

• Returning 404 for an existing path with an unsupported method, leaving callers unable to distinguish a bad URL from a bad method.
• Returning 405 without Allow, preventing clients from discovering the supported methods and violating HTTP semantics.
• Using Access-Control-Allow-Methods in place of Allow, confusing HTTP capability with browser cross-origin permission.
• Recasting every authorization failure as 405, which corrupts security audits, monitoring, and client behavior.
• Letting the gateway and application generate different Allow sets, producing inconsistent responses after proxy caching.

Error, reason, correction

Treating 405 as a generic failure, omitting Allow, or using the CORS header as Allow leaves callers without a next action. Correct the flow by matching the resource first, generating status and headers from one method registry, and testing 404, 403, 405, and preflight separately.

Production implementation

Coordinate routes and proxies

Either pass the application's 405 and Allow through the gateway or define one gateway owner and prevent duplicate overwrites. Maintain a method matrix per API version, including caching, idempotency, authentication, and retry requirements. If a proxy downgrades unknown methods to GET, fix that policy first; otherwise the application never sees the real method.

Observability and compatibility

Log the request method, normalized path, route version, response status, and final Allow set without logging file contents. After receiving 405, a client should stop blindly retrying the same method and use a contract-supported method or upgrade its SDK. For legacy clients, observe misuse in logs and documentation before tightening behavior through a versioned change.

Verification checklist

Contract tests

Build a method matrix for every resource covering: success for registered methods, 405 for an unregistered method, 404 for a missing path, 403 for authorization denial, and equality between Allow and the actual route. Assert status, the header method set, content type, and error-body fields.

Integration and regression

Use a real HTTP client to verify gateway, load balancer, and application behavior together. Test OPTIONS and CORS preflight separately, confirming that Access-Control-Allow-Methods does not replace Allow. During rollout, alert on the 405 rate, method distribution, and error-body parse failures.

Follow-up questions and responses

When can 404 be returned instead of 405?

Return 404 when the path truly does not exist or when a security policy intentionally hides resource existence. Apply that choice consistently for the resource class and document it for clients, logs, and monitoring; different nodes should not randomly return 404 or 405.

Must Allow always include OPTIONS?

Include it only when the resource actually accepts OPTIONS. If the framework handles OPTIONS automatically, verify that its response matches the application route contract; do not add an unimplemented method for visual completeness.

How should dynamic capabilities work?

When method capability varies by tenant, version, or resource state, generate Allow from the current request context and include all capability dimensions in the cache key. A safer default is to limit intermediary caching of 405 or set an explicit cache policy.

Scoring rubric

• Semantic accuracy: explains when 405 applies and why Allow is mandatory.
• Clear boundaries: distinguishes 404, 403, OPTIONS, CORS, and security hiding.
• Practical implementation: gives concrete registry, proxy, error-body, and observability choices.
• Complete verification: covers method matrices, real HTTP paths, rollout metrics, and regression.
• Risk awareness: avoids false method advertising, information leaks, and gateway/application drift.

References

• MDN: 405 Method Not Allowed
• MDN: Allow header
• Postman: HTTP Error 405
• JustAcademy: REST API interview questions

Answering tip

Start with “the resource matched, the method is unsupported, return 405,” then give the actual Allow set. Distinguish 404, 403, OPTIONS, and CORS, and finish with method-matrix tests and proxy consistency.

One-sentence takeaway

405 states that the resource-method combination is invalid, while Allow tells the client which methods are currently valid; together they form a diagnosable HTTP contract.