This post is part of a series that starts with this post.

Withy having looked at a bunch of things we can do with something as simple as an Auto-REST enabled view up to and including adding security, I just want to finish off with showing that having a view in the first place is not needed If all you want is a GET-service for a SQL.

AUTO-Rest gives you many more things automatically, both like all forms of DML. You can of course get it without AUTO-rest, but for now let’s just have a quick look at a read access (GET).

If you go back to the first post in this series, we rest-enabled a view. That is what got us the vw_rest_svc REST service. But why have a view if we’re never using that view except for making a REST GET call? One can build more complex with REST of course, but to just replace with a single statement, this is what we’d do.

begin
  ords_metadata.ords.define_service(
        p_module_name        => 'restsvc'
      , p_base_path          => '/rest_svc'
      , p_pattern            => '.'
      , p_method             => 'GET'
      , p_source_type        => ords.source_type_collection_feed
      , p_source             => 
        'select object_id
              , owner
              , object_name
           from all_objects'
      , p_status             => 'PUBLISHED' 
      , p_items_per_page     => 200
      );
 commit;
end;
/

With that we’re back to being able to get our JSON-response. This specifies to have just GET so that is the only functionality, but all the things we have done has been reading so all of that still works. Test it with cURL.

curl https://.../ords/rest_demo_schema/rest_svc/ | python3 -m json.tool

{
    "items": [
        {
            "object_id": 134,
            "owner": "SYS",
            "object_name": "ORA$BASE"
        },
        <... snip ...>,
        {
            "object_id": 2129,
            "owner": "PUBLIC",
            "object_name": "V$SGASTAT"
        }
    ],
    "hasMore": true,
    "limit": 200,
    "offset": 0,
    "count": 200,
    "links": [
        {
            "rel": "self",
            "href": "https://.../ords/rest_demo_schema/rest_svc/"
        },
        {
            "rel": "describedby",
            "href": "https://.../ords/rest_demo_schema/metadata-catalog/rest_svc/"
        },
        {
            "rel": "first",
            "href": "https://.../ords/rest_demo_schema/rest_svc/"
        },
        {
            "rel": "next",
            "href": "https://.../ords/rest_demo_schema/rest_svc/?offset=200"
        }
    ]
}

Exactly like before, with the only difference that we have changed the default number of rows from 25 to 200. Even with just this single statement variant we get much more control than we get with the Auto-REST. This is a simple start to taking the training wheels off once one has gotten the feet wet with Auto-REST.

The series is now over, but there is of course much more with ORDS, REST, and APEX so I’ll return to this because it is a technology that is as low-code for REST_API as APEX is for WEB-UI. And while being that it gives enough power that it allows the user to after just a short initial hill to climb feel like they are superstars.