Parks staff need automation to create a brand-new work-order resource in the maintenance API. Which HTTP method is appropriate?
Select an answer to reveal the explanation.
Short Explanation
You can use POST to send a new work-order form to the parks inbox, creating something that did not exist before. GET only reads existing work-orders; it will not file a new order for you.
Full Explanation
Creating a brand-new parks work-order resource in a maintenance API is typically done with HTTP POST to the work-orders collection. POST asks the server to create a subordinate resource; the API usually assigns an identifier and returns the created representation or its location. Parks automation that opens new maintenance work should therefore send the work-order payload with POST rather than trying to read records or misuse discovery and diagnostic methods as creation substitutes. GET that only retrieves existing work-orders fails because GET observes what already exists; it does not create a resource. OPTIONS used as a substitute for creating records fails because OPTIONS discovers allowed methods or supports CORS preflight behavior, rather than inserting business resources. TRACE against the API gateway to open a maintenance ticket fails because TRACE is a diagnostic echo method, is often disabled, and has no work-order creation semantics. Exam caveat: APIs can define different creation behavior, so follow the documented contract; this question frames creation on a collection, which maps to POST in standard REST teaching. Operational check: POST a sample work-order in a test environment, verify that a new ID is returned and a subsequent GET retrieves the work-order, and confirm the automation does not rely on GET, OPTIONS, or TRACE for creation side effects.