Open cnasikas opened 1 month ago
Pinging @elastic/response-ops (Team:ResponseOps)
what about public-queries instead of apis-browser? public because we use already public as our work for the browser/frontend and API sounds like we wrap/extend or create our own browser APIs https://developer.mozilla.org/en-US/docs/Web/API
I followed the convention recommended in the docs. Tbh, I also do not like the browser
. We need a name that by reading you understand that the package contains functions to be able to use to make HTTP requests to the alerting REST APIs. Not sure what is the best. I found the public-queries
confusing but maybe it is only me 🙂. What about @kbn/response-ops-endpoints
or @kbn/response-ops-http-apis
?
But doesn't endpoints or http-apis sound like we create the endpoints in there? That's why I came up with queries. My last try, otherwise feel free to go with whatever option, what about @kbn/response-ops-http-client
or @kbn/response-ops-api-client
?
I like the @kbn/response-ops-api-client
proposal but we have to export a client 🙂 not only functions.
It has been noticed that solutions hit our Alerting APIs (public and internal) directly. This is prone to errors because the schema of the request and responses can change for internal APIs and solutions use their types which will be wrong on schema change. We should expose functions that encapsulate our APIs with well-defined types for the request and the response. We should only expose functions for the APIs that are already in use by the solutions teams. For the rest of them, we can do it on a request base. The functions should be on their dedicated package called
@kbn/response-ops-apis-browser
. The folder structure of each function should beExample of a function: