The more I work with the Data API Builder (DAB), the more I lean towards GraphQL instead of REST. Rest isn’t bad, but it’s tough.

This is part of a series of posts on DAB that I’ve written. I also have articles at SQL Server Central about DAB.

Checking the Endpoint

In my first article and DAB, I set up things with defaults and exposed a table. As you can see, my REST endpoint is live and running.

I can also see this in Postman.

Wht if I want to remove this and only look at GraphQL? Let’s see what I need to do.

Removing the REST Runtime

In the config file, there is this section for the REST configuration at runtime.

I can remove this, but I’d hope I didn’t mess up the JSON. This is hard to read. Certainly this is something I can delete, but is there another way?

There is. In the DAB CLI  reference, one of the parameters is –rest.disabled. Let’s try that.

That doesn’t work. Hmmm, OK, let’s add the database type

Apparently init only creates new files.

There is an update verb, but that doesn’t work either.

I guess I’m editing the file. I remove the highlighted section above and the API starts.

Let’s check the REST endpoint. It appears to still work:

In the runtime, I see this log:

Weird. I see an error, but data is returned.

Looking down, I see this in my config for an entity. The REST is enabled.

I’ll change that to false and restart the DAB service. Now I see this. REST is still there, but this path is broken.

If I go to the root for /api, I get a 404. There’s still a response, as there is a service here running GraphQL, but the REST path for /api is gone.

Summary

I’m not sure this really works, as if I enable this for any entity, then the REST call works. If I add any entity without using the –rest: false parameter, the REST path is added by default, so my guess is this is likely to be randomly added back by developers if they don’t have a wrapper around the CLI that ensures no REST paths are enabled.