Creating Swagger UI wrapper for API access to Stardog Cloud hosted server

Not sure how interesting this might be, or whether 'Support" is even the right category for the post, but I saw an older post on API access, and I figured I'd add to the API lore by describing how to use https://editor-next.swagger.io/ to make a quick and dirty wrapper for playing with Stardog's REST API.

Pre-conditions:
These instructions presume that you have set up an endpoint that uses "Basic Auth". I assume that there are instructions on how to do this elsewhere. If here aren't I'd be happy to write that up separately.

In any case, here are the properties for the Basic Auth endpoint that I created:

The significance of creating this endpoint is that has:

  • The server url: https://sd-6276c8eb.stardog.cloud:5820
  • The name of a user: api_access

And, because SSO was switched off when the endpoint was created, we know that this api_access user will use Basic auth to make API calls.

Note that a password (not shown) was provided when the endpoint was created

Setting up wrapper:

  • Download the Stardog Open API metadata: https://stardog-union.github.io/http-docs/openapi.json
  • Open https://editor-next.swagger.io/
  • Drag the downloaded openapi.json file to the left pane of the Swagger Editor UI
  • Either
    • replace "url": "http://localhost:5820" (around line 23) with your endpoint url (in my case https://sd-6276c8eb.stardog.cloud:5820)
    • or add your endpoint as a server, in which case your servers section will look something like:
  "servers": [
    {
      "url": "http://localhost:5820"
    },
      {
      "url": "https://sd-6276c8eb.stardog.cloud:5820"
    }
  ],
  • Add a securitySchemes declaration to your components section (around line 7760) and add a basicAuth scheme to securitySchemes. The first seven lines of JSON in your components section should now look something like:
  "components": {
    "securitySchemes": {
      "basicAuth": {
        "type": "http",
        "scheme": "basic"
      }
    },
  • Add a security section at the end of the JSON metadata. It can actually go anywhere .. it just needs to be a "top-level" item, that is a peer of the components section .. but I elected to put it as the last section of the metadata .. so the last five lines of my modified metadata look like:
,
  security:[
  {basicAuth: []}
  ]
}

Seeing effect of changes:
If you made all of the edits correctly:

  • you should now be able to select your SD Cloud endpoint,
  • and you should be able to open a dialog that allows you to add your user credentials:
  • and every endpoint should now be configured to pass "Basic Auth" info in the HTTP request headers

Testing your Handiwork:
Assuming:

  • the configured user has the proper rights configured,
  • and you have the correct server selected
  • and you have entered credentials for the API user ..

.. you should be able to make a call, just to see if things work properly.
I chose to use the GET /admin/status endpoint, because it doesn't require any parameters, it's close to the top of the page, and, since it's a GET, there is no risk of unwanted mutation of content.

Hi Michael,

Related to your post, FWIW - Stardog uses Swagger to document the REST API, which is available here.

-Paul

I did find that .. In fact, that is the page where I downloaded the metadata.

The reason for my thrashing above was that I was not able to see how to:

  • Alter the Server, in order to direct the calls to the endpoint that I had set up on SD Cloud. It looks as though it is hard-wired to http://localhost:5820
  • Set credentials in order to use the Basic Auth user that I had created.

If I overlooked some capability on that page, my apologies .. but if I didn't, then the ability to configure https://editor-next.swagger.io/ such that it allows you to direct calls to a particular server, using credentials for a particular user, and to observe the responses right there in the browser seems kind of handy.

Postman is nice too, and I experimented with that as well .. but I usually like to use the Swagger UI for initial explorations, because:

  • It puts a decent wrapper around all of the available endpoints, and
  • It allows you to auto-generate client wrappers in a variety of languages