Create Registry Core API v3 w/ QoL improvements

[EricWittmann]

We need to create v3 of the core registry API with the following changes:

• Improved error handling (e.g. proper error codes)
• Consistency across the API
• Better handling of groups and artifacts as containers (see also https://github.com/Apicurio/apicurio-epics/issues/67 )

Subtasks:

• https://github.com/Apicurio/apicurio-registry/issues/3656
• https://github.com/Apicurio/apicurio-registry/issues/3657
• https://github.com/Apicurio/apicurio-registry/issues/3658
  • Group should be editable
  • Group creation operation should have its own input type
  • Group should have editable metadata
  • Groups should be filterable with paging under /groups (GET operation)
  • Groups should be searchable under /search/groups
  • Allow Rules to be configured at Group level
  • Groups can have properties (key/value pairs)
• https://github.com/Apicurio/apicurio-registry/issues/3659
  • No more treating an Artifact like an updatable entity
  • Artifacts can be empty of content (no versions)
  • Artifacts can be created empty
  • Metadata and rules can be configured on empty artifacts
  • Allow delete all Versions and keep the Artifact
  • Only allow / POST operation for simple use-case (no Request header support for Name, Description, etc)
  • Extended JSON content type is used everywhere else and is expanded to include Name, Description, Version etc.
• https://github.com/Apicurio/apicurio-registry/issues/3660
  • Need the ability to test artifact creation, not just update
• https://github.com/Apicurio/apicurio-registry/issues/1929
• https://github.com/Apicurio/apicurio-registry/issues/3676
• Instead of /meta for versions, invert to use /content
• Remove /state - move it into metadata

[jsenko]

Agree with all the changes. A few thoughts:

• Should we also merge metadata and properties? It seems like a similar concept, the current difference is that the metadata are defined/well-known and some of them are set by the server. We could have a free-form key-value properties, with some reserved keys for the known metadata. This would improve extensibility.
• Do we want to keep version state endpoint? Maybe treat is as a known property (metadata).
• Do we want to change anything about the application/create.extended+json content type?

[EricWittmann]

@jsenko I would be interested in a proposal for combining metadata and properties. It's obvious to me how that would be presented in the actual JSON payloads, but it's less clear to me how we would define that in the openapi definition. I have some ideas but don't know how friendly they would be.

[jsenko]

A few more thoughts so I don't forget:

• Rules should be configurable per-group (making groups more usable for pseudo-multitenancy)
• We have three ways of adding new content:
  • POST /groups/{groupId}/artifacts
  • PUT /groups/{groupId}/artifacts/{artifactId}
  • POST /groups/{groupId}/artifacts/{artifactId}/versions Plus the two content types. We should simplify this. This is related to https://github.com/Apicurio/apicurio-epics/issues/67 . Maybe we could have some kind of simplified set of endpoints that will replace POST /groups/{groupId}/artifacts with */* content, and just does the reasonable default thing, for simple use-cases, and have only the extended content type endpoint under /groups/{groupId}/artifacts/{artifactId}/versions
• Unify /admin, /system, /user endpoints?
• Per-group limits endpoint
• Manage /groups/{groupId}/artifacts/{artifactId}/owner using metadata

[EricWittmann]

Done with reference: https://docs.google.com/spreadsheets/d/1rsiVDcy32LmKTNwr2pGP7EMLzSZOaFD5w_g86isLoWA