7446 document rest api#7582
Conversation
ab78686 to
177baef
Compare
| time | ||
| * `DashboardStack` - to create a CloudWatch dashboard showing recorded metrics | ||
| * `BulkExportStack` - to export a whole table as parquet files | ||
| * `RestApiStack` - for a [REST API](../rest-api/README.md) to interact with the instance over HTTPS. Currently early; |
There was a problem hiding this comment.
Think we need a better word than "early" here
Suggest in develop, or something along those lines
| configBucketStack.grantWrite(grantee); | ||
| tableIndexStack.grantReadWrite(grantee); | ||
| stateStoreStacks.grantReadWritePartitions(grantee); | ||
| stateStoreStacks.grantReadWriteAllFilesAndPartitions(grantee); |
There was a problem hiding this comment.
Why was this changed? I don't think editing the table configuration involves files?
There was a problem hiding this comment.
When I was testing the rest api the add table wasn't working and needed this change
There was a problem hiding this comment.
I think this needs raising as a separate bug.
There was a problem hiding this comment.
If the API isn't working we'll want to include the bug fix in the changelog. If we do it in this PR we're likely to miss it when writing the changelog, and we wouldn't have a record that the bug existed.
We could also do with identifying when the bug first occurred, and how it broke.
It's not clear from this PR what the bug is, or why this would be needed. Do you want to clarify it here or just raise a new issue?
| instanceProperties = requireNonNull(builder.instanceProperties); | ||
| addTable = requireNonNull(builder.addTable); | ||
| // Fields may be null when this route is instantiated by the OpenAPI doc generator, which only invokes the | ||
| // openApi* methods below. handle() will fail with an NPE if the route is dispatched a request without them. |
There was a problem hiding this comment.
Why is it necessary to instantiate this class in order to generate the documentation? I'm not sure that needs to be the case?
There was a problem hiding this comment.
Because the methods for generating the openApi doc are instance methods and need to be so that the Generator can loop through all routes calling them.
There was a problem hiding this comment.
Is there another way you could design it?
There was a problem hiding this comment.
I think it feels clunky to support two different modes of instantiation. It feels misleading that some of the fields can be null, when they are required to be non-null for the class to work. It makes the class rather big. The OpenAPI definition isn't actually derived from anything in this class, so I think it doesn't look like it really needs to be all one class?
|
Ready for review |
patchwork01
left a comment
There was a problem hiding this comment.
I also commented on the following previous threads:
| `sendToIngestBatcher.sh`. | ||
|
|
||
| ### Add table | ||
| #### Using the REST API |
There was a problem hiding this comment.
Maybe it would be best to cover the REST API in a single place? A user will know whether they want to use the API or the scripts, and the documentation will be harder to read if it switches between the two.
There was a problem hiding this comment.
That's exactly why I initially had the REST API section separated out which you asked me to change
There was a problem hiding this comment.
I'm not sure what you mean, I don't see a comment where I asked for that. When it was separate I commented that the way it was structured didn't fit with our existing documentation, I didn't suggest a particular change - #7582 (comment).
I think the problem here is there's a lot going on in this PR/issue, including the OpenAPI definitions and the bug fix, as well as the docs changes.
Here's a link to this thread if you're reading this in the review: #7582 (comment)
| ## REST API | ||
|
|
||
| Sleeper has an optional REST API for interacting with a deployed instance over HTTPS. Only "add table" is available | ||
| today; see the [REST API documentation](rest-api/README.md) for deployment, authentication, and endpoint details. The |
There was a problem hiding this comment.
It looks like the link has been removed, we probably still need a link to the documentation from here?
Here's a link to the original thread: #7582 (comment)
patchwork01
left a comment
There was a problem hiding this comment.
I also commented on the thread on the bug fix: #7582 (comment)
| instanceProperties = requireNonNull(builder.instanceProperties); | ||
| addTable = requireNonNull(builder.addTable); | ||
| // Fields may be null when this route is instantiated by the OpenAPI doc generator, which only invokes the | ||
| // openApi* methods below. handle() will fail with an NPE if the route is dispatched a request without them. |
There was a problem hiding this comment.
I think it feels clunky to support two different modes of instantiation. It feels misleading that some of the fields can be null, when they are required to be non-null for the class to work. It makes the class rather big. The OpenAPI definition isn't actually derived from anything in this class, so I think it doesn't look like it really needs to be all one class?
| } | ||
|
|
||
| @Override | ||
| public Operation openApiOperation() { |
There was a problem hiding this comment.
I think these OpenAPI definitions seem like a lot of overhead to require every time we add a new route. It also looks like a lot of work to keep them correct, and I can't see that being practical.
Everywhere I've seen this used, either source code was auto-generated from an OpenAPI definition, or the OpenAPI definition was derived from the source code for the actual endpoints. With this setup, it doesn't look like there's any check that these definitions are accurate? It also doesn't look like it's used for anything specific?
Does this follow AWS' recommendations for documentation of API Gateway REST APIs?
| | Field | Type | Required | Description | | ||
| | ------------- | ----------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | `properties` | object of string → string | Yes | Sleeper [table properties](../property-master.md). Must include `sleeper.table.name`; other properties fall back to instance defaults. | | ||
| | `schema` | object | Yes | The [Sleeper schema](../schema.md) for the new table. Any shape accepted by `SchemaSerDe` is accepted here. | |
There was a problem hiding this comment.
I don't think we can reference SchemaSerDe here, that's the source code and not user-facing. The schema format is documented in the linked file.
| JSON | ||
| ``` | ||
|
|
||
| The instance property lookup above shells out to the config bucket; if you already have the URL to |
There was a problem hiding this comment.
I think the use of "shells out" reads a bit oddly when we're already in a shell. The important bit is it retrieves the properties file from the config bucket.
| `sendToIngestBatcher.sh`. | ||
|
|
||
| ### Add table | ||
| #### Using the REST API |
There was a problem hiding this comment.
I'm not sure what you mean, I don't see a comment where I asked for that. When it was separate I commented that the way it was structured didn't fit with our existing documentation, I didn't suggest a particular change - #7582 (comment).
I think the problem here is there's a lot going on in this PR/issue, including the OpenAPI definitions and the bug fix, as well as the docs changes.
Here's a link to this thread if you're reading this in the review: #7582 (comment)
| ## REST API | ||
|
|
||
| Sleeper has an optional REST API for interacting with a deployed instance over HTTPS. Only "add table" is available | ||
| today; see the [REST API documentation](rest-api/README.md) for deployment, authentication, and endpoint details. The |
There was a problem hiding this comment.
It looks like the link has been removed, we probably still need a link to the documentation from here?
Here's a link to the original thread: #7582 (comment)
Make sure you have checked all steps below.
Issue
Feature". Note that before an issue is finished, you can still make a pull request by raising a separate issue
for your progress.
Tests
Documentation
separate issue for that below.