Closed DSharifi closed 7 months ago
If we now go for a separate
sync_call
endpoint, why do we even introduce av3
? We can just add an endpoint under the existingv2
path; what's speaking against that?
The MR is still a draft. This section in the design doc explains the change better.
I propose changing the behavior of the current /call
endpoint to give synchronous responses, instead of creating a new endpoint, /sync_call
. We bump the API version path from v2
to v3
path since we are changing the behavior of the /call
endpoint.
We also discussed deprecating the v2
endpoints in the future, once developers have had enough time to migrate their projects to use a newer agent that targets the v3
endpoints. However, deprecating v2
endpoints will be a problem for blackholed asset canisters and break them, as they can not be upgraded to use a newer version of agent-js to target /v3
instead of /v2
for sending HTTP requests.
I do not think breaking blackholed asset canisters will be a problem in practice, but I'd like to create a motion proposal and forum post to see how the community sentiment is about deprecating the old endpoints.
CC: @rumenov
If we now go for a separate
sync_call
endpoint, why do we even introduce av3
? We can just add an endpoint under the existingv2
path; what's speaking against that?
I think the idea is to optimize for clarity long term. Maybe we should meet to discuss the pros and cons of the approaches (add v2/sync_call, add v3/ endpoints for all existing, add v3 only for call).
I am also curious if the certified queries will have different arguments than the existing query endpoint and what is the long term plan for them.
If we now go for a separate
sync_call
endpoint, why do we even introduce av3
? We can just add an endpoint under the existingv2
path; what's speaking against that?