Part 4 of 12 in the Oracle EPM Cloud REST API series.
A URL alone only tells Oracle EPM Cloud which resource you are interested in. It does not say what you want done with it. That is the job of the HTTP method, sometimes called the verb, that travels alongside the URL in every request.
Oracle's own documentation puts the general idea plainly: RESTful web services "implement operations that map to the common HTTP methods, such as GET, POST, PUT, and DELETE to retrieve, create, update, and delete resources, respectively."
In the context of Oracle EPM Cloud, that breaks down like this.
GET retrieves information without changing anything. Checking a job's status, listing job definitions, or reading an application's metadata are all GET calls. They are safe to repeat as many times as you like, since a GET never modifies data on its own.
POST creates or executes something new. Submitting a business rule to run, kicking off a data import, or triggering a cube refresh are all POST calls, because each one starts a brand new unit of work, referred to in Oracle's documentation as a job, on the server.
PUT updates something that already exists. Changing a planning unit's approval status or updating a substitution variable's value are typical PUT operations. You are not creating a new object, you are changing an existing one.
DELETE removes something. Clearing a file from the inbox or outbox, or removing an application snapshot, falls under DELETE.
The pattern to remember: GET is read-only and safe to call as often as needed, POST starts new work, PUT changes existing state, and DELETE removes it. In practice, when automating Oracle EPM Cloud administration, the two verbs you will reach for constantly are GET (checking on something) and POST (making something happen). PUT and DELETE show up, but far less often, mostly around metadata and file management tasks.
One nuance belongs here early, because it will matter a great deal a few posts from now: POST calls in Oracle EPM Cloud rarely finish instantly. Submitting a business rule with POST does not mean the rule has finished running by the time you get a response, it means the job has started. Confirming it actually completed successfully is a separate GET call, made afterward, against the job's own ID. That two-step shape (POST to start, GET to check) is the backbone of almost every automation this series builds toward.
Knowing which verb to use is only half the picture. The other half is understanding what Oracle EPM Cloud sends back after each call, which is where HTTP status codes come in.