[ResponseOps][Alerting] Export Alerting API functions to be consumed by solutions
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 be
- response-ops
- apis-broswer
- getRules
- types.ts <--- Request and response types
- get_rules.ts <-- Implementation
- index.ts <-- No barrel exports. Only what is necessary.
Example of a function:
export async function getRules({
http,
req,
}: {
http: HttpSetup;
req: FindRulesRequest;
}): Promise<FindRulesResponse> {
const res = await http.get<FindRulesResponse>(`${BASE_ALERTING_API_PATH}/rule`, {
query: req,
});
return res; <-- we may need to apply transformation from snake case to camel case.
### DoD
- [ ] Create the `@kbn/response-ops-apis-browser`.
- [ ] Find instances of usage of our APIs in the codebase and put an item in this list.
- [ ] Export an API function for the `/internal/alerting/rules/_find` endpoint.
- [ ] Export an API function for the `/internal/rac/alerts/find` endpoint.
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.