deep search: update documentation of supported query parameters#1402
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
stefanhengl
force-pushed
the
stefan-splf-1444-make-deep-search-api-accept-uuids-from-web-client
branch
from
f32376c to
0c0ac56
Compare
| -H 'X-Requested-With: my-client 1.0.0' | ||
| ``` | ||
|
|
||
| ## Accessing conversations via read tokens |
There was a problem hiding this comment.
We could omit this section, because we already document the query parameter in a previous section. However, it might be worth emphasizing this point because it connects the Web UI with the API.
There was a problem hiding this comment.
I think this section is really important and we should probably double down on how this is an alternative to the numeric IDs we never show to the user...
cc @mmanela
There was a problem hiding this comment.
In our API, the questions have numeric IDs and refer to their conversations, which also have integer IDs. If we want to switch to UUIDs, we should switch questions, too. Supporting both, ID and UUID is of course possible, but I don't think it's necessary and it is quite messy in the code and in the documentation.
Using UUID as IDs can also hurt db performance and it doesn't provide an intrinsic order either, which implies other API changes; for example, we have to remove support for id as sort parameter.
I am not against UUID. After all Amp uses them too. I just want to point out that they are often not for free.
If we want to switch to UUIDs for everything I think we should introduce a v2. This gives us the chance to remove ids completely and provide a clean API.
However I don't think that this user request really warrants a new API version. It's quite a specific request and we support it already ;-)
Alternative:
Switch to IDs for everything, which implies adding a flag to the DB that the thread has been shared. The only reason that we have UUIDs in the first place is because all threads are public once a customer enables sharing.
Con: Customers have already created UUID links, so we have to support UUIDs for a while.
There was a problem hiding this comment.
Your argument makes sense, I underestimated the complexity here. I agree that this is a specific ask and it's OK if we don't push this further
stefanhengl
deleted the
stefan-splf-1444-make-deep-search-api-accept-uuids-from-web-client
branch
2 participants
This updates the list of supported query parameters and adds a section about how to access conversations via read tokens.