You can view a REST Data Source on the REST Data Source page as described in Editing a REST Data Source. A newly created Oracle Cloud SaaS application data source has all the operations the end point supports, a Data Profile reflecting all of its attributes, and a root resource name assigned. Once defined, you can use your REST Data Source in any APEX region while building pages. You can also use it programmatically using the appropriate procedures and functions available in the APEX_EXEC package.

Operations

If the endpoint supports them all, the maximum set of wizard created operations includes:

• GET rows with filtering, ordering, and pagination support
• GET row by resource key
• POST (insert)
• PATCH (update)
• DELETE

Data Profile

The Data Profile contains a primary key column named APEX$RESOURCEKEY mapped to the REST service's resource key that uniquely identifies each row. This ensures that all REST services work in a consistent way against any endpoint, including ones whose underlying business object has a single-attribute primary keys, a multiple-attribute primary key, or defines an alternative unique key as a resource key. The data profile also has appropriately defined columns for all other business object attributes. Note that some Fusion Application business objects contain hundreds of standard attributes, and some can be customized to increase that number even further. Chances are very high that your APEX application does not need to work with all of these attributes, but the Create REST Data Source Wizard defines a Data Profile column for all of the attributes. You can streamline the amount of data that will be exchanged between the APEX engine and a particular Oracle Cloud REST Data Source app as follows:

• Delete Data Profile columns you are sure you will never need.
• Mark Data Profile columns as not Visible to the APEX engine, without having to delete them.
• Ensure each region uses only the necessary columns by marking the others as Commented Out, by setting their Server-side Condition to Never, or by deleting them from the region's column list or the page items representing them.

APEX only requests the necessary field data for each region. There is no precise upper-limit on the maximum amount of REST endpoint business object attributes you can work with in a single request, but in practice trying to query the data of hundreds of attributes for a single region, you may encounter runtime exceptions. The actual limit will depend on the length of the attribute names involved and the total number of attributes participating in the query.

To ensure the best experience of working with REST endpoints for Fusion Application business objects containing hundreds of attributes, the Create REST Data Source Wizard defines all the data profile columns for the REST service, and then limits the ones marked Visible to a maximum of 150 columns. If your REST endpoint's business object contains custom fields (whose names are suffixed by " _c "), the wizard tries to give priority to include as many of those as possible in the 150 visible columns that it chooses by default. After the REST Data Source is created, at any time you can adjust which data profile columns are visible by editing the data source and updating its Data Profile.

Root Resource Name Setting

Each REST Data Source has a Root Resource Name setting whose value gets automatically inferred by the Create REST Data Source Wizard, but which can be set manually for Oracle Cloud SaaS Apps REST data sources upgraded from previous APEX releases. This setting identifies the case-sensitive name of the root resource for the endpoint.

When working with an endpoint such as .../latest/employees that defines a "top level business object" like an employee, the Root Resource Name will match the name of the REST resource (for example, employees). However, when defining an REST service for a collection of related child objects such as Vacation Requests that are owned by an employee using an endpoint URL such as .../latest/employees/:empid/child/VacationRequests, the Root Resource Name of this Vacation Requests data source would also be employees since it is part of a tree of data that is owned by the root Employee object. The setting value is optional for top-level REST endpoints since APEX can infer the correct root resource name in that case, but for data sources based on nested child resources, the setting is mandatory.