Revert "Move the openapi source of truth" #44
Conversation
This reverts commit ba95fb0. See Unstructured-IO/unstructured-api#369
awalker4
requested review from
Coniferish,
pawel-kmiecik and
hubert-rutkowski85
| openapi_doc_auth_header: x-api-key | ||
| openapi_docs: | | ||
| - https://api.unstructured.io/general/openapi.json | ||
| - https://raw.githubusercontent.com/Unstructured-IO/unstructured-api/main/openapi.json |
There was a problem hiding this comment.
We don't want to point at the file in repo? https://github.com/marketplace/actions/speakeasy-client-sdk-generation-action#openapi_docs
openapi_docs: |
- ../../openapi.json
Spares us having to manually update it every time something changes (and risking forgetting). Btw, right now it's 404.
There was a problem hiding this comment.
Hopefully should work now that Unstructured-IO/unstructured-api#369 is merged. My thinking is that the source of truth for params should live with the server code, and we'll update whenever we add a new param in unstructured-api. (It will allow both clients to use the same source.) Although, I didn't realize we could supply multiple files - I wonder if we want to keep client specific params in a local openapi.json and let them merge, rather than having to generate a special overlay file.
There was a problem hiding this comment.
Yes, url is 200 now :) I also think that unstructured-api should contain source of truth for clients, but we can't use it now directly as there are too big changes in client from it. So we will have to update the openapi.json in this repo whenever backend changes for some time. My point was that we could use the file from repo because I thought the link points to manually uploaded file. I mistaken it for github gists, but it actually points to the file in repo. So it's perfect (EDIT: except maybe for that it points to file on main branch, so changing the file in other branches would not be visibile to CI, but it seems SDK by this file is generated only from main, so should be ok). Anyway, approving to not prolong this discussion.
Re overlays: because there are big differences between server and client openapis, we probably can't do direct comparison like I planned here: 579f2eb Then overlays don't help but add complexity. In such case for simplicity I think to just have a single openapi.json with hand edited changes, plus a well documented .txt doc with list of those changes.
Re js client: didn't look inside yet. Will look after finishing pdf splitting.
|
Tagging this related PR: Unstructured-IO/unstructured-js-client#28 |
This reverts commit ba95fb0. See Unstructured-IO/unstructured-api#369