Oracle REST Data Services (ORDS) Version 25.2 is now available.
In a previous post, I shared a bit on how to use our new Pre-Authenticated Requests feature to setup temporary but secure access to an ORDS REST Module endpoint.
In that example, I shared the PL/SQL API call to create the PAR on my POST handler, so my IOT Device could post it’s weather data to our Oracle Database, via an ORDS REST API.
DECLARE
l_uri clob;
BEGIN
l_uri := ORDS_PAR.DEFINE_FOR_HANDLER(
p_module_name => 'thatjeffsmith',
p_pattern => 'sensor_data/',
p_method => 'POST',
p_duration => 15769728
);
COMMIT;
dbms_output.put_line(l_uri);
END;
/
But if you’ve read the ORDS 25.2 Readme, you’ll have noticed that PARs now have UI support via our REST Workshop in SQL Developer Web!
Creating and managing PARs in SQL Developer Web
PARs existing at the HANDLER level.
So I can have a resource, such as employees/ with handlers:
- GET
- PUT
- POST
- DELETE…
…and create a PAR for the GET access.
It’s up to me, we support all of them, but that would be 4 PARs for the 4 verbs on employees/ if I wanted that.
So while I’m building my GET handler, I can also work with any PARs I need on that GET handler.

Or if we try the handy kebab button…

A quick demo

Observations:
- we’ll do the math for you on the seconds to intervals
- be sure to capture the URL/token on the response!
- you can easily see how many PARs you’ve issued, and revoke (delete) them at any time
This feature is an example of how our REST API developer interfaces and experience have continued to evolve over the years, and you can expect more! Our next big task is to SIMPIFLY the UI for building and maintaining your REST APIs, so it’s even easier and faster! This will also serve as the template for adding the interface into our VS Code Extension!
About the RESTful Services Interface in APEX
The SQL Workshop in APEX has been around since…forever. And that feature has spawned several other useful utilities including this one for ORDS –

This screen was put together by one of our former ORDS developers whose name rhymes with Doug, more than several years ago, and it also pre-dated SQL Developer Web.
Over the years, we’ve added tons of features in ORDS, that haven’t been brought into the APEX dev screens for ORDS REST APIs. To give you an idea, did you know that ORDS REST APIs and our IDE in SQL Developer Web supports…
- REST handler editors with intellisense, syntax highlighting, :bind variable insertion, etc
- built-in Swagger tooling pages, complete with ‘Try it out’ and code gen snippets
- cURL snippets generation for any AutoREST or REST Module API
- managing your OAuth2 clients (reminder OAUTH plsql -> ORDS_SECURITY)
- importing and generating OpenAPI specs
- a Graphiql editor for using GraphQL over your enabled tables/views
It doesn’t make sense to maintain two different web IDEs for managing ORDS REST APIs, so the legacy interface in APEX has been deprecated. The screen won’t completely go away, but it will become read-only. If you need to make a new API or update and existing one, you’ll need to hop on over to SQL Developer Web to do that work.
For an APEX developer, if you’re workspace’s schema has been REST Enabled, you can either use your existing APEX authenticated session to come over to the ORDS screens, or you can use the database username/password to start a new session. If you’re doing this work a LOT, you can simply bookmark the URL for the REST workshop in SQL Developer Web – our URLs are always the same.

While you’re in SQL Developer Web, a few things you might be interested in…
If you haven’t used it before, it’s always there, remember, APEX can’t run without ORDS, and SQL Developer Web is a default feature of ORDS.
The SQL worksheet was architected by the same person who write the SQL worksheet you’re using in APEX…yeah, that guy. But this one offers way more features, and supports running way more in terms of SQL, PL/SQL, and scripts.
Some other screens you might find useful:
2 Comments
It was a lot of fun to write the REST Workshop in APEX, and had I stayed on the APEX team it would have been fun to continue to develop it as long as it made sense.
But, you’re right, it doesn’t make sense to have to maintain the same code so many places. It’s the right move to deprecate it.
So long old friend… It’ was fun.
It was great, and your work has touched/impacted thousands of users. That’s a pretty fricken cool legacy!