Part 2 of 12 in the Oracle EPM Cloud REST API series.
Before touching anything Oracle specific, it helps to understand what a REST API is in plain terms, because the acronym scares people off more than the concept deserves.
REST stands for Representational State Transfer. It is an architectural style for building web services that communicate over standard HTTP, the same protocol your browser uses every time it loads a page. Rather than opening a persistent connection or requiring specialized client software, a REST API exposes resources (an application, a job, a business rule) at predictable web addresses, and lets you act on those resources using a small set of standard HTTP methods.
For Oracle EPM Cloud, every interaction follows the same three-step shape.
The client app sends a request. Your script, a scheduler, or an integration platform starts the exchange by sending an HTTP request to a specific URL.
Oracle EPM Cloud processes the request. The service receives the request, checks who is asking, and carries out whatever action was asked for: running a rule, pulling data, checking a status.
A JSON response comes back. Oracle EPM Cloud replies with a response formatted as JSON, a lightweight, readable text format, containing the data or confirmation the client asked for.
That is the whole model. There is no special protocol to learn beyond HTTP, and no special data format beyond JSON. If you have ever filled out a web form or clicked a download link, you already understand the mechanics. A REST call is simply a more structured version of the same request and response exchange, written to be read by a program rather than a person.
One thing to lock in early: this same three-step shape applies across every Oracle EPM Cloud module, not just Planning. Financial Consolidation and Close, Account Reconciliation, Tax Reporting, Enterprise Profitability and Cost Management, and Enterprise Data Management each expose their own REST APIs, and every one of them follows this exact client request, server processing, JSON response pattern. Learn it once here and it transfers directly, no matter which module you end up automating.
There is also no state carried between calls. Each request stands alone and includes everything the server needs to understand it: where to send it, what action to take, and (for many calls) what data to act on. That statelessness is part of what makes REST APIs so easy to script. You do not need to log in and maintain a session the way you would in a browser. You authenticate on each call (more on that in part six) and the server treats every request as a fresh, self-contained instruction.
With the concept in place, the next question is practical: what does an actual Oracle EPM Cloud REST URL look like, and what do its pieces mean? That is where the series goes next, in Anatomy of an Oracle EPM Cloud REST URL.