Backend: Prepare new endpoint to process Slack event API
About
Link unfurling &6389 is the first Slack feature that will use the Slack events API.
All Slack events that we subscribe to in future will be sent to a single endpoint of GitLab, regardless of the Slack workspace or event type. So the endpoint needs to be very performant.
For this first iteration, this issue is to prepare the events endpoint and process the challenge, but not process any events yet. The processing of events will start in #358677.
Proposal
- The API class should be namespaced
API::Integrations::SlackEvents. - The API route should be
api/v4/integrations/slack_events.
For this issue, the endpoint will just need to:
- Verify the request https://api.slack.com/authentication/verifying-requests-from-slack.
- Respond to a challenge which Slack issues in order to let you configure the endpoint to be the Event Request URL of your Slack app. I think the response needs to happen in request rather than on a queue.
Click to see previous proposal to use `internal` namespace. Abandoned after #358676 (comment 909790491)
The endpoint should be part of the internal API:
- The API class should be namespaced
API::Internal::Integrations::SlackEvents. - The API route should be
api/v4/internal/integrations/slack/events.
GitLab API Rate limits?
We should check what rate limits there may be on the internal API endpoints and whether this endpoint could be exempt. Note, Slack itself does rate limit its requests (scoped by workspace) but this is separate.
Update: The API rate limit work is in a separate issue #360749.