thinwrap_notifications_transport behaviour (thinwrap_notifications v1.2.0)
View SourceThe bring-your-own HTTP seam.
The library never depends on a third-party HTTP client. It defines this one
callback and ships thinwrap_notifications_httpc (OTP httpc) as the default.
To use hackney, gun, Finch, … implement the behaviour and pass it in the
config:
Config = #{provider => sendgrid, api_key => Key,
transport => {my_hackney_transport, #{pool => mail}}}.request/2 sends one request and returns one response. Rules:
- A non-2xx answer is a response, never an error: return
{ok, #{status := 429, ...}}. The connector owns status-to-error mapping, so a 429 still reads asrate_limited. - Any
{error, Reason}(connection refused, DNS, TLS, timeout) is reported asprovider_unavailablewith nostatus. Only the kind of the reason (its leading atom, e.g.timeoutorfailed_connect) is kept: a client's error term may embed the request URL, and for Telegram or a chat webhook the URL path IS the credential. {error, {connector_error, Error}}surfaces a ready-madethinwrap_notifications:connector_error/0unchanged (the default transport uses it to refuse non-httpsURLs).- Never follow redirects: a 3xx must come back as a response, or the provider's credentials would be re-sent to wherever it points.
- Header values arrive as UTF-8 binaries whose code points are all ≤ 0xFF
(the library rejects anything else first); send them as Latin-1, as
httpcdoes with a character list.
Summary
Types
-type method() :: get | post.