Date: December 2015
Log Oracle REST Data Services bugs and issues using My Oracle Support.
If you want to use the database default tablespaces (default and temporary tablespaces) for ORDS_METADATA schema and ORDS_PUBLIC_USER user when installing ORDS, then you can use the following script:
@ords_manual_install_db_def_tbs p1
Example:
@ords_manual_install_db_def_tbs /logs/
The ORDS manual install script no longer prompts you for ORDS_PUBLIC_USER default and temporary tablespaces. You must specify the tablespaces from the command line.
@ords_manual_install p1 p2 p3 p4 p5
Example:
@ords_manual_install /logs/ SYSAUX TEMP SYSAUX TEMP
If you want to use the database default tablespaces (default and temporary tablespaces) for ORDS_METADATA schema and ORDS_PUBLIC_USER user when installing ORDS from the command line, you must install ORDS in silent (simple) mode and remove the following tablespace entries in your /path/to/params/ords_params.properties file:
schema.tablespace.default=SYSAUX schema.tablespace.temp=TEMP user.tablespace.default=USERS user.tablespace.temp=TEMP
To install ORDS in silent (simple) mode using the database default tablespaces:
java -jar ords.war java -jar ords.war install simple
This release provides support for upgrading ORDS in a containter database (CDB) from 3.0.1 to 3.0.2.
To upgrade Oracle REST Data Services in a CDB, follow these steps:
ORACLE REST DATA SERVICES/pathToScripts/scripts/upgradeshow con_name
/pathToScripts/scripts/upgrade/ords_manual_upgrade.sql script. For example:
@ords_manual_upgrade /ords_logs/
Where the /ords_logs/ argument specifies the location for the Oracle REST Data Services log files (must already exist).
There are two main causes of 404 - Not Found errors:
Using /ords instead of /ords/ (ORDS 3.0.0 only, fixed in 3.0.1 and later).
Oracle REST Data Services is deployed at a context-root of /ords/,
in previous versions there was logic to handle the case where a user accessed
/ords instead of /ords/. In ORDS 3.0.0 this functionality
was regressed, but it has been fixed in this release. If you access /ords
your browser will be redirected to /ords/.
Not configuring the PL/SQL Gateway
If you want to to use Oracle Application Express or you wish to access PL/SQL Stored Procedures, then you must enable the PL/SQL Gateway during the installation process.
A quick way to check if you have completed this step is to check in the
configuration folder if the file named: conf/apex.xml exists.
If it does not exist then it implies that the PL/SQL Gateway was not configured.
If you do not use Application Express then
there will be no stored procedure available to serve the /ords/ resource.
This means that accessing this URL will produce a 404 - Not Found status,
this is expected.
Use the misc.defaultPage configuration setting to specify the name
of a PL/SQL procedure to serve the /ords/ resource. This must be a PL/SQL
procedure that takes zero arguments, and uses Oracle Web Agent (OWA) APIs to produce
a HTML response. This setting can be configured in SQL Developer under:
View > REST Data Services > Administration
and then when editing a configuration, under:
REST Data Services > Environment > PL/SQL Gateway > Default Web Page
If you don't wish to use Oracle Application Express or PL/SQL procedures then
you do not need to configure the PL/SQL Gateway, however as explained above
accessing /ords/ will always produce a 404 - Not Found status, since there is nothing to serve this resource, this is expected.
Standalone Mode can now serve aribtrary static resources via it's new document root feature. To see instructions on how to use the document root, use the help command:
java -jar ords.war help standalone
java -jar ords.war standalone [--port] [--apex-images] [--context-path] [--static-context-path] [--doc-root] [--parameterFile]
Launch Oracle REST Data Services in standalone mode
Options:
[--port] HTTP listen port, default 8080
[--apex-images] Path to the folder containing
static resources required by
APEX
[--context-path] The context path where Oracle
REST Data Services is
located, defaults to /apex
[--static-context-path]The Context path where
Application Express static
resources are located,
defaults to /i
[--doc-root] Points to the location where
static resources, to be
served under the / root
server path are located.
[--parameterFile] Specify the location of the
parameter file to use.
Defaults to
params/ords_params.properties.
For example the following command would configure the document root to be /var/www/html:
java -jar ords.war standalone --doc-root /var/www/html 2015-06-16 22:33:19.899:INFO::main: Logging initialized @1253ms Jun 16, 2015 10:33:20 PM oracle.dbtools.standalone.StandaloneJetty setupDocRoot INFO: The document root is serving static resources located in: /var/www/html
The document root has the following features:
Files named index.html or index.htm are treated
as welcome files, and are served in place of the folder resource
that contains them.
For example /var/www/html/index.html would serve as the
resource for http://localhost:8080/
Files with a .html or .htm file extension
are served without without their file extension.
For example /var/www/html/docs/readme.html is served as:
http://localhost:8080/docs/readme. If a client accesses
http://localhost:8080/docs/readme.html, then the client will be redirected to http://localhost:8080/docs/readme.
video/mp4url-mapping.xml failed to work correctlyORA-06550 PLS-00103 during installjava -jar ords.war version/ords instead of /ords/ produces a 404 Not Found error on Weblogic, GlassFish and Tomcaturl-mapping.xml file being stored in the wrong folder@ApplicationScoped services are not started when command line is activeHEAD operation/store prefix on NoSQL Database resources has been eliminated, support has been added for the new DDL capability introduced
in NoSQL Database 3.2.5, enabling DDL statements to be issued via a RESTful Endpoint.uninstall command, see java -jar ords.war help uninstall for more information.POST request with the filter clause as the body of the
POST request.Oracle REST Data Services includes the following new functionality:
Oracle REST Data Services 2.0.x required Oracle Application Express 4.2 or later to be installed in order to define and use RESTful Services. In Oracle REST Data Services 3.0.x Oracle Application Express is not required. Instead Oracle REST Data Services is able to install it's own schema on the first run of Oracle REST Data Services. The installation process is simple and fast.
JSON documents can now be stored in and retrieved from document collections managed by Oracle Database. SODA for REST provides an interface to the Oracle Database Document Store for NoSQL style application development.
Using Oracle SQL Developer 4.1 and later you can expose database tables and views as REST API endpoints, enabling data stored in the tables or views to be created, queried, updated and deleted using REST.
This release adds support for exposing Oracle NoSQL Database tables as REST API endpoints. The data stored in the tables can be created, queried, updated and deleted using REST.
The behvaiour of the following existing features has been enhanced:
Oracle REST Data Services now stores it's metadata about RESTful Services in it's
own schema (named: ORDS_METADATA). This means it is no longer
required to install Oracle Application Express in order to define
RESTful Services.
Since Application Express is not used to define the metadata this means that these RESTful Services cannot be edited by Application Express, instead you must use Oracle SQL Developer 4.1 or later to edit the RESTful Services.
Note that existing RESTful Services defined in Application Express continue to be fully supported, see more about this in the Application Express section below.
Any database schema can be enabled to define RESTful Services, before a schema can define RESTful Services, it must enabled for use with Oracle REST Data Services. This
can be done using SQL Developer 4.1 or in SQLPlus by invoking the ords.enable_schema stored procedure:
SQL> connect scott Enter password: Connected. SQL> exec ords.enable_schema; PL/SQL procedure successfully completed. SQL> commit; Commit complete. SQL>
Oracle is converging and unifying APIs and document formats across all products that support REST. To support this two new Source Types have been added for Resource Handlers:
'JSON Collection' is the default source type. Note that 'Query', 'JSON Query Feed', and 'Query (with one result only)' continue to be supported, but deprecated and customers are encouraged to switch to using the source types instead.
The standardization effort also affects how pagination is performed, previously resources were paginated using the ?page=N query parameter. This syntax
conintues to be supported for existing source types, but the new 'JSON Collection' source type uses the standardized ?offset=O&limit=L query parameters. This syntax
gives clients more flexibility about indicating the size of pages they can handle.
This release introduces support for cookie based first party authentication of RESTful Services. This feature enables web applications deployed on the same web server (origin) as the the RESTful Services to authenticate with the the RESTful Services using a cookie instead of OAuth 2.0 access tokens.
This makes it much easier for first party applications to consume RESTful Services. This feature is supported in ORDS enabled schemas and NoSQL data stores.
Oracle REST Data Services can authenticate against any user repository configured in the host application server. In the previous release users were typically defined in the Application Express user repository, in this release users are typically defined in the application server user respository.
Standalone now uses Jetty to provide the JEE runtime environment required by Oracle REST Data Services. Jetty is well proven, mature and being continuously improved.
Oracle REST Data Services continues to support RESTful Services defined in Oracle Application Express. The 'JSON Collection' and 'JSON Item' source types are not supported in RESTful Services defined in Oracle Application Express.
Oracle SQL Developer can be used to edit RESTful Services defined in Application Express or Oracle REST Data Services. A database schema that is associated with an Application Express workspace can be enabled for Oracle REST Data Services 3.0.x RESTful Services, but doing so will mean only the RESTful Services defined in the ORDS_METADATA schema will be editable via Oracle SQL Developer.
TIMESTAMP type does not work/sign-in/ interactive sign in form. Accessing /sign-in/ in APEX workspaces will produce a 404 status.