4 Replies Latest reply on May 21, 2019 6:55 PM by Trevis

    ORDS URI

    Trevis

      Hi all,

       

      When looking around, it seems there is a mainstream pattern when it comes to naming API.

       

      Most of the API is provided under an "API" subdomain, and then a version (v1, v2 or date - whatever) is added to the URL, for i.e., api.mydomain.com/v1/employers to get all employers.

       

      However, when using ORDS to provide API for let's say, my APEX application, the URL gets very unnecessarily long, for i.e., api.mydomain.com/ords/<SCHEMA>/<MODULE>/<TEMPLATE>

       

      So, if I have a RESTful to expose a list of employers, I have to have a minimum of 4 levels for example api.mydomain.com/ords/myuniqueschema/myuniquemodule/employers

       

      Would there be a way to setup ORDS or maybe deploy it in such a way I could have more control in this naming structure?

       

      Thanks in advance

        • 1. Re: ORDS URI
          Olafur T

          Hi,

           

          Yes, but you need to have a proxy frontend to hide your ORDS servers. I do this in all my setups for security reasons (I don't want /ords/ exposed to the big bad internet) and NGINX (my front end web server) is really good at file delivery, proxy passing, gzip compression, TLS https, https2. etc...

           

          So I will expose a single api at a time, and I and my developers are required to use a naming convention so that each API can be easily mapped.

           

          A nginx clause will look like:

           

          location /api/ {

          charset utf-8;

          proxy_pass http://ordsserver:8080/ords/{workspace or schema alias}/api/;

          proxy_set_header Host $host;

          charset_types application/json;

          override_charset on;

          include proxy.conf;

          }

           

          So now, any service made in that schema is exposed as long as the base path starts with /api/

           

          This way you can cherry pick what services you want exposed.

           

          Regards

          Oli

          • 2. Re: ORDS URI
            Trevis

            Hi,

             

            I agree we shouldn't be exposing /ords/whatever to the big bad internet.

             

            However, even though having rewrites rules in place within NGINX, the ORDS still generates JSON responses having the full link with /ords/whatever/etc/etc when we have pagination in the response.

             

            You can try yourself. I made an NGINX rewrite rule to call api.mydomain.com/v1/employees which actually is "mapped" to my internal module called organizations (just for this example).

             

            Look the screenshot. Even though calling my proper "employees" endpoint, the JSON contains the full and real URI from ORDS.

             

            ords.png

            • 3. Re: ORDS URI
              Olafur T

              Well, in comes NGINX to the rescue again.

               

              Take a look at Module ngx_http_sub_module

               

              So my nginx config is filled with sub_filter text search/replace to make the urls look right in any response.

                sub_filter_once off;

                sub_filter http:// https://;

                sub_filter_types application/json;

                sub_filter backend.com/ords/schema_alias/api/ frontend.com/api/;

               

              Sub_filter is basically a text/replace so your telling nginx: For any application/json body, find "backend.com/ords/schema_alias/api/" and replace it with "frontend.com/api/"

               

              My point is that this is very much possible and pretty easy to accomplish. I have multiple API's exposed this way (for AngulaJS, React, Mobile, etc frontends) and all the links look right and point to the correct place.

               

              Regards

              • 4. Re: ORDS URI
                Trevis

                Thanks Olafur T

                 

                Reading a bit more about sub_filters and changing a bit my NGINX rules made the trick.