You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
📚 ♻️ ✨ Adds response to retriers. General documentation.
- Passes a response, if any, to retriers.
- Improves documentation of various HTTPNetworking types.
- Converts `HTTPMethod` to a struct for external extensibility purposes.
Copy file name to clipboardExpand all lines: Sources/HTTPNetworking/HTTPClient.swift
+19-12Lines changed: 19 additions & 12 deletions
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@ import Foundation
2
2
3
3
/// `HTTPClient` creates and manages requests over the network.
4
4
///
5
-
/// The client also provides common functionality for all ``HTTPRequest`` objects, including encoding and decoding strategies,
5
+
/// The client provides common functionality for all ``HTTPRequest`` objects, including encoding and decoding strategies,
6
6
/// request adaptation, response validation and retry stratagies.
7
7
///
8
8
/// Generally an ``HTTPClient`` is used to manage the interaction with a single API service. Most APIs
@@ -12,20 +12,37 @@ import Foundation
12
12
/// If your API requires a custom encoder or decoder, you can provide your own custom ones to the client. These encoder and decoders
13
13
/// will then be used for all requests made using the client.
14
14
///
15
+
/// ## Adaptors
16
+
///
15
17
/// If your API requires some sort of repetitive task applied to each request, rather than manipulating it at each call, you can make use of an
16
18
/// ``HTTPRequestAdaptor``. The adaptors that you provide to the client will all be run on a request before it is sent to your API.
17
19
/// This provides you with an opportunity to insert various headers or perform asyncrounous tasks before sending the outbound request.
18
20
///
21
+
/// > Important: All adaptors will always run for every request.
22
+
///
23
+
/// ## Validators
24
+
///
19
25
/// Different APIs require different forms of validation that help you determine if a request was successful or not.
20
26
/// The default ``HTTPClient`` makes no assumptions about the format and/or success of an API's response. Instead, you can make use of an
21
27
/// ``HTTPResponseValidator``. The validators that you provide the client will all be run on the response received by your API.
22
28
/// This provides you with an opportunity to determine wether or not the response was a success and failure, and consolidate potentially repeated logic in one place.
23
29
///
30
+
/// > Important: Validators will be run one by one on a request's response. If any validators determines that the response is invalid,
31
+
/// the request will fail and throw the error returned by that validator. No other subsequent validators will be run for that run of a request.
32
+
///
33
+
/// ## Retriers
34
+
///
24
35
/// Sometimes you may want to implement logic for handling retries of failed requests. An ``HTTPClient`` can make use of an
25
36
/// ``HTTPRequestRetriers``. The retriers that you provide the client will be run when a request fails.
26
37
/// This provides you with an opportunity to observe the error and determine wether or not the request should be sent again. You can implement complex retry
27
38
/// logic across your entire client without having to repeat yourself.
28
39
///
40
+
/// > Important: Retriers will be run one by one in the event of a failed request. If any retrier concedes that the request should not be retried,
41
+
/// the request will ask the next retrier if the request should be retried. If any retrier determines that a request should be retired, the request will
42
+
/// immedietly be retired, without asking any subsequent retriers.
43
+
///
44
+
/// ## Request Manipulation
45
+
///
29
46
/// In addition to providing adaptors, validators and retriers to your entire client, you can provide additional configuration to each
30
47
/// request using a chaining style syntax. This allows you to add additional configuration to endpoints that you may want to provide further
31
48
/// customization to beyond the standard configuration at the client level.
@@ -44,17 +61,7 @@ import Foundation
44
61
/// let response = try await request.run()
45
62
/// ```
46
63
///
47
-
/// > Note: All adaptors, validators and retriers at the client level will be run first, after which the
48
-
/// request configurations at the request level will be run.
49
-
///
50
-
/// > Important: All adaptors will always run for every request.
51
-
///
52
-
/// > Important: Validators will be run one by one on a request's response. If any validators determines that the response is invalid,
53
-
/// the request will fail and throw the error returned by that validator. No other subsequent validators will be run for that run of a request.
54
-
///
55
-
/// > Important: Retriers will be run one by one in the event of a failred request. If any retrier concedes that the request should not be retried,
56
-
/// the request will ask the next retrier if the request should be retried. If any retrier determines that a request should be retired, the request will
57
-
/// immedietly be retired, without asking any subsequent retriers.
64
+
/// > Note: For all adaptors, validators and retriers, the client level plugins will run before the request level plugins
Copy file name to clipboardExpand all lines: Sources/HTTPNetworking/HTTPRequest.swift
+16-9Lines changed: 16 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -8,16 +8,19 @@ import Foundation
8
8
///
9
9
/// To send an ``HTTPRequest`` call ``run()``. This will perform the network request ant return the expected response type.
10
10
///
11
-
/// You can adapt the `URLRequest`, before it gets sent out, by calling ``adapt(_:)`` or ``adapt(with:)``.
12
-
/// By providing an ``AdaptationHandler`` or ``HTTPRequestAdaptor``, you can perform various asyncronous logic before a request gets sent
11
+
/// Each ``HTTPRequest`` is setup with concurrency in mind. In-flight requests are periodically checked for `Task` cancellation and will approprietly stop
12
+
/// when their parent task is cancelled.
13
+
///
14
+
/// > Tip: You can adapt the `URLRequest`, before it gets sent out, by calling methods like ``adapt(_:)`` or ``adapt(with:)``.
15
+
/// By providing an ``AdaptationHandler`` or any ``HTTPRequestAdaptor``, you can perform various asyncronous logic before a request gets sent
13
16
/// Typical use cases include things like adding headers to requests, or managing the lifecycle of a client's authorization status.
14
17
///
15
-
/// You can validate the `HTTPURLResponse`, before it gets deocded, by calling ``validate(_:)`` or ``validate(with:)``.
16
-
/// By providing a ``ValidationHandler`` or ``HTTPResponseValidator``, you can perform various validations before a response is decoded.
18
+
/// > Tip: You can validate the `HTTPURLResponse`, before it gets deocded, by calling methods like ``validate(_:)`` or ``validate(with:)``.
19
+
/// By providing a ``ValidationHandler`` or any ``HTTPResponseValidator``, you can perform various validations before a response is decoded.
17
20
/// Typical use cases include things like validating the status code or headers of a request.
18
21
///
19
-
/// You can retry the ``HTTPRequest`` if it fails by calling ``retry(_:)`` or ``retry(with:)``.
20
-
/// By providing a ``RetryHandler`` or ``HTTPRequestRetrier``, you can determine if a request should be retried if it fails.
22
+
/// > Tip: You can retry the ``HTTPRequest`` if it fails by calling retry methods like ``retry(_:)`` or ``retry(with:)``.
23
+
/// By providing a ``RetryHandler`` or any ``HTTPRequestRetrier``, you can determine if a request should be retried if it fails.
21
24
/// Typical use cases include retrying requests a given number of times in the event of poor network connectivity.
22
25
publicclassHTTPRequest<Value:Decodable>{
23
26
@@ -69,6 +72,8 @@ public class HTTPRequest<Value: Decodable> {
0 commit comments