Introduce ui and db API namespaces

[dmos62]

Fixes #1029

Splits our API views into two namespaces:

• /api/db/v0/*
  • hosts endpoints that describe and interact with Postgres objects relatively directly
• /api/ui/v0/*
  • hosts endpoints that describe and interact with Mathesar abstractions that are useful for user interfaces, such as Mathesar types or filters

For example:

• /api/db/v0/databases/1/functions/ describes the low-level functions API;
  • previously, /api/v0/databases/1/functions
• /api/ui/v0/databases/1/types/ describes the high-level UI abstractions,
  • previously, /api/v0/databases/1/types

At the moment of writing, only the Mathesar types endpoint is on the ui namespace. The rest of the endpoints just get the db/ segment inserted in the middle. More ui endpoints will follow, e.g. the upcoming (revamped) filters API.

Checklist

• My pull request has a descriptive title (not a vague title like Update index.md).
• My pull request targets the master branch of the repository
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added tests for the changes I made (if applicable).
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no
  visible errors.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[dmos62]

@kgodey @pavish @seancolsen please review changes, particularly to API URL structure. I'm still making subtle changes, but I'd like to get a sanity-check review early.

[kgodey]

@dmos62 Please associate this PR with the issue #1029. Also note that the issue renamed the "abstractions" namespace to "ui" for clarity and brevity.

[seancolsen]

@dmos62 Having only read the PR description (and not spent the time to look at the diff), I can offer the following thoughts as a high-level sanity check:

• Looks good!
• I don't have an opinion on abst vs ui

[pavish]

@dmos62 Based on @kgodey's comment here I assumed we'd have the client-specific endpoints named as ui instead of abst.

I'm in favour of naming the client specific endpoints as ui since we may have more APIs in the future that are focused on things like frontend layout, which are not necessarily related to Mathesar abstractions

[dmos62]

@pavish @seancolsen @kgodey I think ui is a better name. I hadn't noticed the proposal. I'll change abst to ui. Thanks for sanity check.

[dmos62]

Changed title and description to say that we'll use ui + db instead of abst + db namespaces.

[kgodey]

@dmos62 Can you fix merge conflicts in this PR?

[pavish]

@dmos62 There are some frontend changes on master which are not present in this PR yet. We'll update the frontend urls once this PR is upto date with master.

[pavish]

@dmos62 @kgodey @seancolsen I've added a commit 5fbb064 for the frontend changes.

The commit is a quick workaround to move this PR fast, and I've created a follow-up issue #1054 to deal with frontend changes we'll need in the future.

[dmos62]

@pavish Excuse the premature ping. I see you've started working on the frontend changes 👍

[pavish]

@dmos62 The frontend changes are done as mentioned in the above comment. This PR can be marked ready, if this is the only change you've been waiting for.

[dmos62]

A change I've omitted to mention until now is that the file containing Django filters has been renamed to dj_filters.py: mathesar/api/filters.py → mathesar/api/dj_filters.py.

This was done, because we're introducing a lot of code, including namespaces, that are named "filters" and reference Mathesar filters. Having a mathesar/api/filters.py file is confusing, because that's a reference to a different filter (the Django filter). So, I've named the file dj_filter to distinguish it from, for example, the upcoming mathesar/api/serializers/filter.py or mathesar/filters/.

In retrospect, I should have done that with the PR that adds the new filtering API. In the interest of saving time, I'd rather not move this change to that PR.

[kgodey]

In the interest of saving time, I'd rather not move this change to that PR.

That's fine.

[kgodey]

Looks good, nice work @dmos62 and @pavish.

[kgodey]

Usually we name the test files similarly to the file they're testing, I'd consider renaming this to ui_types or putting this in tests/api/ui. Please make this change in a future PR, though, since I don't want to block merge.

[kgodey]

@seancolsen This needs your approval as a frontend codeowner.