Description of how the response body should be handled. Needs to be specified upfront so that the response is always consumed and hence there are no requirements on client code to consume it. An exception to this are unsafe streaming and websocket responses, which need to be consumed/closed by the client.
Request-specific tags which can be used by backends for logging, metrics, etc. Not used by default.
Encodes the given parameters as form data.
Encodes the given parameters as form data.
If content type is not yet specified, will be set to
application/x-www-form-urlencoded
.
If content length is not yet specified, will be set to the length of the number of bytes in the url-encoded parameter string.
Encodes the given parameters as form data using utf-8
.
Encodes the given parameters as form data using utf-8
.
If content type is not yet specified, will be set to
application/x-www-form-urlencoded
.
If content length is not yet specified, will be set to the length of the number of bytes in the url-encoded parameter string.
Encodes the given parameters as form data.
Encodes the given parameters as form data.
If content type is not yet specified, will be set to
application/x-www-form-urlencoded
.
If content length is not yet specified, will be set to the length of the number of bytes in the url-encoded parameter string.
Encodes the given parameters as form data using utf-8
.
Encodes the given parameters as form data using utf-8
.
If content type is not yet specified, will be set to
application/x-www-form-urlencoded
.
If content length is not yet specified, will be set to the length of the number of bytes in the url-encoded parameter string.
If content type is not yet specified, will be set to
application/octet-stream
.
If content type is not yet specified, will be set to
application/octet-stream
.
If content type is not yet specified, will be set to
application/octet-stream
.
If content type is not yet specified, will be set to
application/octet-stream
.
If content length is not yet specified, will be set to the length of the given array.
If content type is not yet specified, will be set to text/plain
with the given encoding.
If content type is not yet specified, will be set to text/plain
with the given encoding.
If content length is not yet specified, will be set to the number of bytes in the string using the given encoding.
Uses the utf-8
encoding.
Uses the utf-8
encoding.
If content type is not yet specified, will be set to text/plain
with utf-8
encoding.
If content length is not yet specified, will be set to the number of
bytes in the string using the utf-8
encoding.
If content type is not yet specified, will be set to
application/octet-stream
.
If content type is not yet specified, will be set to
application/octet-stream
.
If content type is not yet specified, will be set to
application/octet-stream
.
If content type is not yet specified, will be set to
application/octet-stream
.
If content length is not yet specified, will be set to the length of the given file.
If content type is not yet specified, will be set to
application/octet-stream
.
If content type is not yet specified, will be set to
application/octet-stream
.
If content length is not yet specified, will be set to the length of the given file.
Adds the given header to the end of the headers sequence, if the value is defined.
Adds the given header to the end of the headers sequence, if the value is defined. Otherwise has no effect.
Adds the given header to the end of the headers sequence.
Adds the given header to the end of the headers sequence.
Adds the given header to the end of the headers sequence.
If there's already a header with the same name, should it be dropped?
Adds the given header to the end of the headers sequence.
Adds the given header to the end of the headers sequence.
If there's already a header with the same name, should it be dropped?
When the request is sent, if reading the response times out (there's no activity for the given period of time), a failed effect will be returned, or an exception will be thrown
When a POST or PUT request is redirected, should the redirect be a POST/PUT as well (with the original body), or should the request be converted to a GET without a body.
When a POST or PUT request is redirected, should the redirect be a POST/PUT as well (with the original body), or should the request be converted to a GET without a body.
Note that this only affects 301 and 302 redirects. 303 redirects are always converted, while 307 and 308 redirects always keep the same method.
See https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections for details.
Specifies the target type to which the response body should be read.
Specifies the target type to which the response body should be read.
Note that this replaces any previous specifications, which also includes
any previous mapResponse
invocations.
Description of how the response body should be handled.
Description of how the response body should be handled. Needs to be specified upfront so that the response is always consumed and hence there are no requirements on client code to consume it. An exception to this are unsafe streaming and websocket responses, which need to be consumed/closed by the client.
Sends the request, using the given backend.
Sends the request, using the given backend. Only requests for which the method & URI are specified can be sent.
The required capabilities must be a subset of the capabilities provided by the backend.
For synchronous backends (when the effect type is Identity), Response is returned directly and exceptions are thrown. For asynchronous backends (when the effect type is e.g. scala.concurrent.Future), an effect containing the Response is returned. Exceptions are represented as failed effects (e.g. failed futures). The response body is deserialized as specified by this request (see RequestT.response). Known exceptions are converted by backends to one of SttpClientException. Other exceptions are thrown unchanged.
Request-specific tags which can be used by backends for logging, metrics, etc.
Request-specific tags which can be used by backends for logging, metrics, etc. Not used by default.
(Since version ) see corresponding Javadoc for more information.
Sends the request, using the backend from the implicit scope.
Sends the request, using the backend from the implicit scope. Only requests for which the method & URI are specified can be sent.
The required capabilities must be a subset of the capabilities provided by the backend.
For synchronous backends (when the effect type is Identity), Response is returned directly and exceptions are thrown. For asynchronous backends (when the effect type is e.g. scala.concurrent.Future), an effect containing the Response is returned. Exceptions are represented as failed effects (e.g. failed futures). The response body is deserialized as specified by this request (see RequestT.response). Known exceptions are converted by backends to one of SttpClientException. Other exceptions are thrown unchanged.
(Since version 3.0.0) use request.send(backend), providing the backend explicitly
Describes a HTTP request, along with a description of how the response body should be handled.
The request can be sent using a SttpBackend, which provides a superset of the required capabilities.
Specifies if the method & uri are specified. By default can be either: * Empty, which is a type constructor which always resolves to None. This type of request is aliased to PartialRequest: there's no method and uri specified, and the request cannot be sent. * Identity, which is an identity type constructor. This type of request is aliased to Request: the method and uri are specified, and the request can be sent.
The target type, to which the response body should be read.
The backend capabilities required by the request or response description. This might be
Any
(no requirements), Effect (the backend must support the given effect type), Streams (the ability to send and receive streaming bodies) or sttp.capabilities.WebSockets (the ability to handle websocket requests).Description of how the response body should be handled. Needs to be specified upfront so that the response is always consumed and hence there are no requirements on client code to consume it. An exception to this are unsafe streaming and websocket responses, which need to be consumed/closed by the client.
Request-specific tags which can be used by backends for logging, metrics, etc. Not used by default.