Spec: Initial OpenAPI Spec for a Rest Catalog #3770

kbendick · 2021-12-18T00:27:37Z

This is a follow up to the original PR, #3561, as the discussion there got too large.

We mostly handle namespace related concerns here. Table related objects will come in a follow up PR.

I have followed up on comments and suggestions that were brought up on the other PR, as well as some conclusions that we've come to in the meeting.

The easiest way to view this document is by importing the YAML directly into editor.swagger.io

rest_docs/rest-catalog-open-api.yaml

rdblue · 2021-12-18T00:46:36Z

rest_docs/rest-catalog-open-api.yaml

+          description: Wrapper for the response of a successful request
+      example: { "data": { ... } }
+
+    ResponseErrorObject:


Should these responses go under responses? Is there a distinction?

There really isn't much of a distinction. It's possible to define a bit more things from within the schema section, but I'll check if I actually am using any of those anymore or not.

So TIL it seems that originally there was just schemas. So it has some of the most support for JSON schema and things (like pattern checks that can be added as javax annotations etc).

Other things are newer and less feature rich. I've seen several tutorials with basic error classes, and they've mostly done it via schemas. I'm not sure if that's just to lessen the overhead for the article, but since we're getting rid of the data wrapper, I'm going to keep the error wrapper in schemas for now.

Keeping the ResponseErrorObject in schemas allows it to have much more control over what is and is not excepted, what's required to be defined, etc.

I'm open to moving it, but for now it seems like just getting rid of the data wrapper and the top level wrapper and keeping ResponseErrorObject would be good.

rdblue · 2021-12-18T00:46:53Z

rest_docs/rest-catalog-open-api.yaml

+
+components:
+  #######################################################
+  # Common Parameter Definitions Used In Several Routes #


Nice to have this deduplication!

rest_docs/rest-catalog-open-api.yaml

rdblue · 2021-12-18T01:00:13Z

rest_docs/rest-catalog-open-api.yaml

+                description: whether the underlying data was purged or is being purged
+
+    GetNamespaceResponse:
+      description: Returns a namespace and the properties stored on it


This should probably mention that if properties are not supported the properties are optional? Or maybe they must be sent but can be empty?

How I have it currently, on the response, it's defaulted to { }. As within the Iceberg code, we don't really have the concept of a Namespace without properties. It's just implicit in some places that it's not supported.

I'll throw the words optional or when supported on there though to be more precise.

Updated. I also indicated that namespaces is a required field, as well as gave a default value of an empty object to properties and marked is as the equivalent of @Nullable.

When the properties field is null, it indicates the server doesn't support namespace properties. If it returns an empty object, then there are simply no properties presently stored on this namesapce.

We don't have to keep that way of distinguishing null vs {}, especially as there's no way to describe it in the OpenAPI document that I'm aware of, but it seemed like the easiest way to indicate truly empty vs not supported (and thus empty).

rdblue · 2021-12-18T01:00:49Z

rest_docs/rest-catalog-open-api.yaml

+    delete:
+      tags:
+        - Catalog API
+      summary: Drop a namespace from the catalog. Namespace must be empty.


In the future, we may want to add a cascade option.

Yeah. I hesitated to add this in (especially as I've been working on adding cascade support), but it is on the interface definition (as indicated by the @throws section of the javadoc):

iceberg/api/src/main/java/org/apache/iceberg/catalog/SupportsNamespaces.java

Lines 98 to 105 in c5d3d1c

/**

* Drop a namespace. If the namespace exists and was dropped, this will return true.

*

* @param namespace a namespace. {@link Namespace}

* @return true if the namespace was dropped, false otherwise.

* @throws NamespaceNotEmptyException If the namespace is not empty

*/

boolean dropNamespace(Namespace namespace) throws NamespaceNotEmptyException;

Yeah, we wanted to avoid boolean parameters on the catalog API where we could. The problem here is that it would be really inefficient to use the rest of this API to do a cascading drop because the client would need potentially hundreds of requests to drop each table and namespace individually, and the requests have relatively high latency. We may want to add a cascade flag to the catalog API as well, or a new method (dropNamespaceCascade).

rest_docs/rest-catalog-open-api.yaml

rdblue

Overall, this looks good to me. I think that one of the main things to do is add consistency since there are a lot of differences that make it hard to consume as the yaml spec. I think that part of the motivation is to not have a huge number of schemas and response types so this is embedding them in some of the routes. But that ends up being a little confusing overall.

rest_docs/rest-catalog-open-api.yaml

szehon-ho

It's great there's a spec, had a few small questions , from a first glance.

rest_docs/rest-catalog-open-api.yaml

szehon-ho · 2021-12-21T23:08:44Z

rest_docs/rest-catalog-open-api.yaml

+                $ref: '#/components/responses/DropTableResponse'
+              example: { "dropped": true, "purged": false }
+        202:
+          description: Accepted - for use if purgeRequested is implemented as an asynchronous action.


Just curious, any way to check if async action finished?

Yeah. At present we've left it out for simplicity (as there's already been a lot of discussion around just this), so it will be include it in a follow up PR, but there can be a callback URL that a client can subscribe to to get notification messages etc.

https://swagger.io/docs/specification/callbacks/

rest_docs/rest-catalog-open-api.yaml

szehon-ho · 2021-12-21T23:11:57Z

rest_docs/rest-catalog-open-api.yaml

+        401:
+          description: Unauthorized
+        404:
+          description: Not Found


Below we have NoSuchTable and NoSuchNamespace, curious, should we follow it? (Sorry I guess it was already commented but I didn't follow the resolution)

That's ok. Here, where there's just a response code and a description, in OpenAPI terms that means that there is no response body.

I've done it here for HEAD requests, which aren't supposed to return a response body. However, several well-known systems such as S3 still do have a response body with HEAD requests, so we might allow for that anyway.

rest_docs/rest-catalog-open-api.yaml

rdblue · 2021-12-21T23:59:53Z

rest_docs/rest-catalog-open-api.yaml

+        Check if a table exists within a given namespace. This request does not return a response body.
+      responses:
+        200:
+          description: OK - Table Exists


@rymurr and @jackye1995, what do you think about adding a body to the HEAD responses? I think it would be nice to do for consistency.

in that case, I feel it's better to use POST /v1/tables/head to express such operation, otherwise I am not sure what is going to happen for an open-api generated client.

Wouldn't it be better to use a GET request to /v1/namespaces/{namespace}/tables/{table}/exists instead?

But I don't think that's worth it. Let's just leave this as-is.

I think it's fine as-is for now. But a lot of libraries seem to allow bodies for HEAD requests. We should consider it in the future though. I know there are "the standard(s)" but quite a number of well used libraries do seem to deviate from them now and then for practical purposes.

rdblue · 2021-12-22T00:01:44Z

rest_docs/rest-catalog-open-api.yaml

+              examples:
+                NoSuchNamespaceExample:
+                  $ref: '#/components/examples/NoSuchNamespaceError'
+    head:


I'm wondering if we actually want this. It makes sense to have a HEAD route for tables since loading them can be expensive (sending the full metadata JSON). But here you may as well run the GET route because it's simple to look up the database params.

I'd say we keep it for now but consider dropping it. Possibly we can mark it as optional somehow in a follow up?

Okay, since we are not going to add bodies to the HEAD responses, I think that we should remove this. There isn't a significant benefit that I can think of. We can always add it later if someone wants it.

rdblue · 2021-12-22T00:02:43Z

I'm +1 for committing this. I think it's a great start on the REST catalog spec and that the namespace basics are ready to go.

rest_docs/rest-catalog-open-api.yaml

jackye1995 · 2021-12-22T21:00:33Z

rest_docs/rest-catalog-open-api.yaml

+          description: Unauthorized
+        404:
+          description: Not Found
+


nit: extra empty line

actually I realize some places have extra lines for each HTTP verb section, and some don't, just make sure it's consistent.

+1 for consistency. I like the empty line between verbs.

I have updated to be consistent with empty lines between verbs, including an empty line after the path and parameters and the first verb.

jackye1995 · 2021-12-22T21:05:52Z

rest_docs/rest-catalog-open-api.yaml

+        Check if a table exists within a given namespace. This request does not return a response body.
+      responses:
+        200:
+          description: OK - Table Exists


in that case, I feel it's better to use POST /v1/tables/head to express such operation, otherwise I am not sure what is going to happen for an open-api generated client.

rest_docs/rest-catalog-open-api.yaml

jackye1995 · 2021-12-22T21:18:17Z

rest_docs/rest-catalog-open-api.yaml

+                NoSuchNamespaceExample:
+                  $ref: '#/components/examples/NoSuchNamespaceError'
+
+  /v1/namespaces/{namespace}/properties:


Maybe I missed the discussion last time, but I still don't understand why we cannot use PUT /v1/namespaces/{namespace} for this. I would assume if we have some special properties for namespace in the future, we still want to have the ability to update that anyway.

My takeaway from the discussion was that PUT is typically used to set the entire state and should be idempotent. If we were specifically setting the properties to a specific set, PUT would be appropriate. Since we are sending changes and not the complete state, POST is better so that it is more clear what is happening.

thanks for the explanation!

jackye1995

Thanks for having this new PR out! I have mostly nitpicking comments, but overall this looks like a very great start!

The big questions I have are:

namespace property, can we just use PUT namespace for that
/v1/tables/rename, can we use /v1/table-ops/rename or something else to make the path more self-explanatory
I think we do need 5xx and 400 error definitions in the spec based on RFC 7231, and we can simplify the error response using a universal error schema.

jackye1995 · 2021-12-22T21:28:48Z

rest_docs/rest-catalog-open-api.yaml

+        404:
+          description: Not Found
+
+  /v1/tables/rename:


I wonder if we can use a different word from tables for action paths, because tables already means a table resource in the REST-based path. Using another word like table-ops might be more self-explanatory for the purpose of the route.

I don't really see a downside to using tables here. I don't think it is confusing to have some operations under tables and still use a namespace path for individual table operations.

rest_docs/rest-catalog-open-api.yaml

kbendick · 2022-01-03T05:46:36Z

Thanks for your review @jackye1995

The big questions I have are:

namespace property, can we just use PUT namespace for that

My one concern with using an unqualified PUT namespace (unqualified meaning nothing in the path) is that backend frameworks would need to be able to handle any shape of body depending on what is being updated. For namespace, that would only be properties as far as I can tell, so this one might not be too bad.

/v1/tables/rename, can we use /v1/table-ops/rename or something else to make the path more self-explanatory

I'm presently against using anything with table-ops in the name for now, only as we have had a decent amount of discussion on topics so far, but table-ops is still yet to be fully discused.

Can we can mentally mark it as potentially re-namable to table-ops or something if we go with that after we discuss more of the routes that involve table-ops? I feel like that's going to be a bigger discussion (using most of the table-ops).

I also feel that table-ops is maybe too resource oriented vs just tables, but that's a discussion for table-ops in general which I'm sure will be soon.

I think we do need 5xx and 400 error definitions in the spec based on RFC 7231, and we can simplify the error response using a universal error schema.

Yes we do. I have seen them with exactly 400 and 5xx (e.g. in the Confluent Kafka REST OpenAPI spec I recently found). I will add those tomorrow (more or less just as is on that doc)!

kbendick · 2022-01-03T05:49:13Z

Thanks for your review @jackye1995

The big questions I have are:

namespace property, can we just use PUT namespace for that

My one concern with using an unqualified PUT namespace (unqualified meaning nothing in the path representing that it's a properties request) is that backend frameworks would need to be able to handle any shape of body depending on what is being updated. For namespace, that would only be properties as far as I can tell, so this one might not be too bad. But for tables etc, that could get unwieldy and I don't love the idea of using a plain PUT for namespace and then not necessarily doing that for tables etc. The PUT namespaces would still more or less need to have the same body to differentiate between properties to remove and properties to upsert.

/v1/tables/rename, can we use /v1/table-ops/rename or something else to make the path more self-explanatory

I'm presently against using anything with table-ops in the name for now, only as we have had a decent amount of discussion on topics so far, but table-ops is still yet to be fully discused.

Can we can mentally mark it as potentially re-namable to table-ops or something if we go with that after we discuss more of the routes that involve table-ops? I feel like that's going to be a bigger discussion (using most of the table-ops).

I also feel that table-ops is maybe too resource oriented vs just tables, but that's a discussion for table-ops in general which I'm sure will be soon.

I think we do need 5xx and 400 error definitions in the spec based on RFC 7231, and we can simplify the error response using a universal error schema.

Yes we do. I have seen them with exactly 400 and 5xx (e.g. in the Confluent Kafka REST OpenAPI spec I recently found). I will add those tomorrow (more or less just as is on that doc)!

jackye1995 · 2022-01-03T19:24:07Z

I'm presently against using anything with table-ops in the name for now, only as we have had a decent amount of discussion on topics so far, but table-ops is still yet to be fully discused.

Sure. In that case the only big thing I see currently missing is the 400 response, I will approve when that is added.

Some pending discussions in my mind after this PR are:

if it's better to have specific operation routes for non-RESTful operations
head table/namespace operation with response, if we do that what set of fields should be in the response
if pagination of response is needed when there are too many metadata log or snapshots
progress tracking for table purge
drop namespace cascade

kbendick · 2022-01-03T19:33:34Z

Thanks for the pending thoughts @jackye1995! I'll respond a bit, and then we'll keep these for later discussion as well (assuming there will be more discussion groups / follow up PRs etc)

if it's better to have specific operation routes for non-RESTful operations

Agreed.

head table/namespace operation with response, if we do that what set of fields should be in the response

So currently, there's no set of fields in the response for HEAD requests. That's what the response code and just the string description represents. Technically, HEAD requests are not supposed to have a response body. However, so many famous APIs do that I think we can add them in a follow up.

if pagination of response is needed when there are too many metadata log or snapshots

I had brought up pagination for one or two routes, but it was deemed as somewhat premature. I think eventually we will definitely need some kind of pagination for sure.

progress tracking for table purge

Will be coming in a follow up.

drop namespace cascade

That one is not currently implemented, but I agree. Once we finish implementing it, it should be easy to add in. We can start considering where to put it in the API here sooner. Probably as a query parameter I would think.

jackye1995 · 2022-01-03T21:02:20Z

HEAD requests are not supposed to have a response body

Yes I mean to have another API with a GET verb so that it can have a response.

kbendick · 2022-01-04T00:41:24Z

Overall, this looks good to me. I think that one of the main things to do is add consistency since there are a lot of differences that make it hard to consume as the yaml spec. I think that part of the motivation is to not have a huge number of schemas and response types so this is embedding them in some of the routes. But that ends up being a little confusing overall.

Another thing I only recently discovered is that many of these things can be split across several files. A CLI tool is then used to bundle them together if need be, but it might be good to consider that in the future to make consuming an ever-growing document a lot simpler.

Not going to do that for now as that's probably something to discuss (it does add complexity as well for the reader), but it might be something we can find a trade off for.

kbendick · 2022-01-04T00:47:08Z

HEAD requests are not supposed to have a response body

Yes I mean to have another API with a GET verb so that it can have a response.

Ahh that makes sense. I'm still not personally opposed to having a response body in a HEAD request, as users can likely ignore it given that it's a HEAD request. And given that there are a number of well used APIs that do have them.

But for now I think it's probably best to put that into the backlog as several people have had strong-ish opinions about it. The "backlog" meaning the work I'll be returning to more or less right after this PR as well as whatever side work I also have going 😄

rdblue · 2022-01-04T01:00:20Z

@jackye1995, it looks like we're mostly in agreement now:

if it's better to have specific operation routes for non-RESTful operations

head table/namespace operation with response, if we do that what set of fields should be in the response

if pagination of response is needed when there are too many metadata log or snapshots

progress tracking for table purge

drop namespace cascade

For 1, I think we're just trying to decide on the path for the /tables/rename route, right? I like the simplicity of tables and I don't think it will be confusing to have operation routes there. That's where I'd add multi-table transactions as well, which don't cleanly fit into a single REST resource.

For 2, I think we should remove the HEAD request for namespaces and leave the tables HEAD request without response bodies. We're probably agreed?

3, 4, and 5 are not strictly required so I like the idea of adding them in follow-ups in parallel. That way we can start iterating on other areas with this as the basis.

kbendick · 2022-01-04T01:31:39Z

@jackye1995, it looks like we're mostly in agreement now:

if it's better to have specific operation routes for non-RESTful operations

head table/namespace operation with response, if we do that what set of fields should be in the response

if pagination of response is needed when there are too many metadata log or snapshots

progress tracking for table purge

drop namespace cascade

For 1, I think we're just trying to decide on the path for the /tables/rename route, right? I like the simplicity of tables and I don't think it will be confusing to have operation routes there. That's where I'd add multi-table transactions as well, which don't cleanly fit into a single REST resource.

For 2, I think we should remove the HEAD request for namespaces and leave the tables HEAD request without response bodies. We're probably agreed?

3, 4, and 5 are not strictly required so I like the idea of adding them in follow-ups in parallel. That way we can start iterating on other areas with this as the basis.

I'm in agreement on 1, that /tables/rename makes sense to me. It's just referencing tables in general.

I've gone ahead and removed the HEAD request for namespaces. We can always add it back in in the future if need be. I agree that returning the whole table object for an existence check might be relatively expensive, and so it makes sense to keep the HEAD check for tables. I'm still not opposed to adding response bodies to the HEAD requests eventually, but that can be a topic for another day if need be.

And then agreed on 3,4,5. The sooner we can get the initial document in, the sooner we can make smaller changes that are more digestible and can also work more in parallel 😄

kbendick · 2022-01-04T01:50:43Z

There's a failing Hive test that by definition can't be related to this PR (as this PR only adds an initial YAML document).

rymurr · 2022-01-04T17:13:13Z

Hey all, I just got back today. Will review this asap tomorrow morning. Hope I am not holding anyone up?

rdblue · 2022-01-04T17:51:06Z

Should be fine. Thanks for taking a look, @rymurr!

jackye1995

looks good to me, thanks for all the work!

rdblue · 2022-01-05T22:20:42Z

@rymurr, any comments? We'd like to start working on the follow ups if you have a chance to take a look.

kbendick · 2022-01-06T05:21:33Z

@rymurr, any comments? We'd like to start working on the follow ups if you have a chance to take a look.

cc @nastra as well @rymurr in case you have any final comments on the doc as it is. I know it's a lot to ingest, but I think if we can get this initial doc in, then we can hopefully make things smaller and begin to follow a more consistent pattern that we'll adapt to as we all work more with OpenAPI.

Please keep in mind this is just the first of many patches and things to get this off the ground, so that work can begin somewhat more parallelized. Also, once we're all working on this API, if things need to be changed for practical reasons etc, I'm not opposed to that. I think those things will become more apparent as we make more progress. 😄

…for table resource for now. Also update the list namespaces example description.

rymurr · 2022-01-07T09:37:23Z

Please don't wait for me. I will get to it next week and we can do a follow up if I raise anything.

…

On Thu, Jan 6, 2022 at 6:21 AM Kyle Bendickson ***@***.***> wrote: @rymurr <https://github.com/rymurr>, any comments? We'd like to start working on the follow ups if you have a chance to take a look. cc @nastra <https://github.com/nastra> as well @rymurr <https://github.com/rymurr> in case you have any final comments on the doc as it is. I know it's a lot to ingest, but I think if we can get this initial doc in, then we can hopefully make things smaller and begin to follow a more consistent pattern that we'll adapt to as we all work more with OpenAPI. Please keep in mind this is just the first of many patches and things to get this off the ground, so that work can begin somewhat more parallelized. Also, once we're all working on this API, if things need to be changed for practical reasons etc, I'm not opposed to that. I think those things will become more apparent as we make more progress. 😄 — Reply to this email directly, view it on GitHub <#3770 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPNXIL4GEPQKYMPM3KLX53UUURGTANCNFSM5KJ7LIWA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

rdblue · 2022-01-07T21:58:14Z

I merged this and we can pick up changes from @rymurr's review as we extend this. Thanks @jackye1995 and everyone on the original PR for all the input, and especially to @kbendick for getting this ready!

kbendick force-pushed the rest-catalog-interface-spec-v2 branch from 4ee9289 to 15ffde3 Compare December 18, 2021 00:29

rdblue changed the title ~~[Rest Catalog] Initial OpenAPI Spec for a Rest Catalog~~ Spec: Initial OpenAPI Spec for a Rest Catalog Dec 18, 2021

rdblue reviewed Dec 18, 2021

View reviewed changes

rest_docs/rest-catalog-open-api.yaml Outdated Show resolved Hide resolved

rdblue reviewed Dec 18, 2021

View reviewed changes

rest_docs/rest-catalog-open-api.yaml Outdated Show resolved Hide resolved

kbendick force-pushed the rest-catalog-interface-spec-v2 branch from 15ffde3 to 1d659ba Compare December 18, 2021 00:42

rdblue requested changes Dec 18, 2021

View reviewed changes

rest_docs/rest-catalog-open-api.yaml Outdated Show resolved Hide resolved

rest_docs/rest-catalog-open-api.yaml Outdated Show resolved Hide resolved

rdblue reviewed Dec 18, 2021

View reviewed changes

rest_docs/rest-catalog-open-api.yaml Outdated Show resolved Hide resolved

rdblue reviewed Dec 18, 2021

View reviewed changes

rest_docs/rest-catalog-open-api.yaml Outdated Show resolved Hide resolved

rdblue reviewed Dec 18, 2021

View reviewed changes

rest_docs/rest-catalog-open-api.yaml Outdated Show resolved Hide resolved

rdblue reviewed Dec 18, 2021

View reviewed changes

rest_docs/rest-catalog-open-api.yaml Outdated Show resolved Hide resolved

rdblue reviewed Dec 18, 2021

View reviewed changes

rest_docs/rest-catalog-open-api.yaml Outdated Show resolved Hide resolved

rdblue reviewed Dec 18, 2021

View reviewed changes

rest_docs/rest-catalog-open-api.yaml Show resolved Hide resolved

rdblue reviewed Dec 18, 2021

View reviewed changes

rest_docs/rest-catalog-open-api.yaml Outdated Show resolved Hide resolved

rdblue reviewed Dec 18, 2021

View reviewed changes

rest_docs/rest-catalog-open-api.yaml Show resolved Hide resolved

rdblue reviewed Dec 18, 2021

View reviewed changes

rest_docs/rest-catalog-open-api.yaml Outdated Show resolved Hide resolved

rdblue reviewed Dec 18, 2021

View reviewed changes

rest_docs/rest-catalog-open-api.yaml Outdated Show resolved Hide resolved

rdblue reviewed Dec 18, 2021

View reviewed changes

rest_docs/rest-catalog-open-api.yaml Outdated Show resolved Hide resolved

rdblue reviewed Dec 18, 2021

View reviewed changes

rest_docs/rest-catalog-open-api.yaml Outdated Show resolved Hide resolved

kbendick force-pushed the rest-catalog-interface-spec-v2 branch from 4871563 to 2f27baa Compare December 18, 2021 02:51

rdblue reviewed Dec 19, 2021

View reviewed changes

rest_docs/rest-catalog-open-api.yaml Show resolved Hide resolved

kbendick force-pushed the rest-catalog-interface-spec-v2 branch from 2b48812 to 7ef36d8 Compare December 21, 2021 20:30

szehon-ho reviewed Dec 21, 2021

View reviewed changes

rdblue reviewed Dec 21, 2021

View reviewed changes

rdblue reviewed Dec 22, 2021

View reviewed changes

rdblue approved these changes Dec 22, 2021

View reviewed changes

jackye1995 reviewed Dec 22, 2021

View reviewed changes

kbendick force-pushed the rest-catalog-interface-spec-v2 branch from a4a3f5c to d1f3e23 Compare January 3, 2022 05:51

kbendick force-pushed the rest-catalog-interface-spec-v2 branch from 7278319 to 118fc52 Compare January 4, 2022 00:37

jackye1995 approved these changes Jan 5, 2022

View reviewed changes

kbendick force-pushed the rest-catalog-interface-spec-v2 branch from df8cf5f to ce8c924 Compare January 5, 2022 17:32

kbendick added 2 commits January 5, 2022 21:34

[Rest Catalog] Initial OpenAPI Spec for Namespaces

98f19cd

Remove HEAD route for namespace due to response body concerns, leave …

e09e509

…for table resource for now. Also update the list namespaces example description.

kbendick force-pushed the rest-catalog-interface-spec-v2 branch from ce8c924 to e09e509 Compare January 6, 2022 05:36

rdblue merged commit 88e5be7 into apache:master Jan 7, 2022

flyrain mentioned this pull request Feb 16, 2022

Support Iceberg Metadata storage in a variety of engines #3997

Closed

	/**
	* Drop a namespace. If the namespace exists and was dropped, this will return true.
	*
	* @param namespace a namespace. {@link Namespace}
	* @return true if the namespace was dropped, false otherwise.
	* @throws NamespaceNotEmptyException If the namespace is not empty
	*/
	boolean dropNamespace(Namespace namespace) throws NamespaceNotEmptyException;

Spec: Initial OpenAPI Spec for a Rest Catalog #3770

Spec: Initial OpenAPI Spec for a Rest Catalog #3770

Conversation

kbendick commented Dec 18, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rdblue left a comment

Choose a reason for hiding this comment

szehon-ho left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kbendick Dec 21, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rdblue Dec 21, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rdblue commented Dec 22, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kbendick Jan 4, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jackye1995 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kbendick commented Jan 3, 2022

kbendick commented Jan 3, 2022

jackye1995 commented Jan 3, 2022

kbendick commented Jan 3, 2022 • edited Loading

jackye1995 commented Jan 3, 2022

kbendick commented Jan 4, 2022

kbendick commented Jan 4, 2022

rdblue commented Jan 4, 2022 • edited Loading

kbendick commented Jan 4, 2022

kbendick commented Jan 4, 2022

rymurr commented Jan 4, 2022

rdblue commented Jan 4, 2022

jackye1995 left a comment

Choose a reason for hiding this comment

rdblue commented Jan 5, 2022

kbendick commented Jan 6, 2022

rymurr commented Jan 7, 2022 via email

rdblue commented Jan 7, 2022

kbendick commented Dec 18, 2021 •

edited

Loading

kbendick Dec 21, 2021 •

edited

Loading

rdblue Dec 21, 2021 •

edited

Loading

kbendick Jan 4, 2022 •

edited

Loading

kbendick commented Jan 3, 2022 •

edited

Loading

rdblue commented Jan 4, 2022 •

edited

Loading