This represent my journey for sending multiple requests at once when I cannot use modern HTTP capabilities, discovering and rediscovering RFCs. Teaching me that I didn't really need anything new, but to compose with different existing things.
forms in several passes ➔ Contact multiple endpoints at the same time ➔ Exploit a resource right after its creation without waiting for the result to be sent 1 What is the subject?
forms in several stages ➔ Contact multiple endpoints at the same time ➔ Exploit a resource right after its creation without waiting for the result to be sent ➔ Addresses the inability of a server to determine the optimum order of processing for a logical collection of requests, before attempting to process any of the individual requests 1 What is the subject?
every company has a modern MACH architecture, with a nice orchestration flow. ➔ Or because in your Kubernetes Cluster your Ingress is a proxy that only deals with port 80 from within 1 What is the subject?
a new multipart/http Content-Type header ➔ Each subquery is described in the payload, separated by a delimiting string ➔ Each subquery is identified by a Content-ID to associate its response 1 2 Research for specification
a new multipart/http Content-Type header ➔ Each subquery is described in the payload, separated by a delimiting string ➔ Each subquery is identified by a Content-ID to associate its response ➔ We cannot assume the execution order of each subquery 1 2 Research for specification
a new multipart/http Content-Type header ➔ Each subquery is described in the payload, separated by a delimiting string ➔ Each subquery is identified by a Content-ID to associate its response ➔ We cannot assume the execution order of each subquery ➔ The main query cannot be cached, but the subqueries can be 1 2 Research for specification
a new multipart/http Content-Type header ➔ Each subquery is described in the payload, separated by a delimiting string ➔ Each subquery is identified by a Content-ID to associate its response ➔ We cannot assume the execution order of each subquery ➔ The main query cannot be cached, but the subqueries can be ➔ The queries are encapsulated by a message/http or an application/http 1 2 Research for specification
to one endpoint ➔ Use a new multipart/http Content-Type header ➔ Each subquery is described in the payload, separated by a delimiting string ➔ Each subquery is identified by a Content-ID to associate its response ➔ We cannot assume the execution order of each subquery ➔ The main query cannot be cached, but the subqueries can be ➔ The queries are encapsulated by a message/http or an application/http
emails Usually) ➔ multipart/digest (Like alternative, but usually messages from multiple people) ➔ multipart/parallel (Intended to be processed in parallel if the software can) ➔ A sub message can be Multipart itself 1 2 Research for specification
URL of subsequent queries. ➔ Values of a response body in the query part of the url or in the body of subsequent queries. 1 2 Research for specification
URL of subsequent queries. ➔ Values of a response body in the query part of the url or in the body of subsequent queries. ➔ Individual processing in the order of reception. 1 2 Research for specification
URL of subsequent queries. ➔ Values of a response body in the query part of the url or in the body of subsequent queries. ➔ Individual processing in the order of reception. ➔ Stop at the first error, unless the continue-on-error preference is specified. 1 2 Research for specification
URL of subsequent queries. ➔ Values of a response body in the query part of the url or in the body of subsequent queries. ➔ Individual processing in the order of reception. ➔ Stop at the first error, unless the continue-on-error preference is specified. ➔ Apply all, or nothing. 1 2 Research for specification
URL of subsequent queries. ➔ Values of a response body in the query part of the url or in the body of subsequent queries. ➔ Individual processing in the order of reception. ➔ Stop at the first error, unless the continue-on-error preference is specified. ➔ Apply all, or nothing. ➔ The queries are encapsulated by a message/http or an application/http 1 2 Research for specification
URL of subsequent queries. ➔ Values of a response body in the query part of the url or in the body of subsequent queries. ➔ Individual processing in the order of reception. ➔ Stop at the first error, unless the continue-on-error preference is specified. ➔ Apply all, or nothing. ➔ The queries are encapsulated by a message/http or an application/http ➔ Odata has been standardized by OASIS and approved as an international ISO/IEC standard. 1 2 Research for specification
headers ➔ and body In addition to the header fields that begin with "Content-" each sub-request MUST redefine the start-line with its own How does a sub-message defines itself?
such ordering of responses and MUST use the Content-ID headers to correlate HTTP request and response messages in the Batch Requests and Batch Responses. RFC 2392
MUST use the Content-ID headers to correlate HTTP request and response messages in the Batch Requests and Batch Responses. Even if some or all of the contained requests fail individually, the server SHOULD respond with a status of either 200 OK, 202 Accepted or eventually 207 Multi-Status. 1 2 3 New specification draft-snell-http-batch-01
MUST use the Content-ID headers to correlate HTTP request and response messages in the Batch Requests and Batch Responses. Even if some or all of the contained requests fail individually, the server SHOULD respond with a status of either 200 OK, 202 Accepted or eventually 207 Multi-Status. 1 2 3 New specification This is also possible for sub-responses
response SHOULD include an indication of the requests current status and either include a Location header to a status monitor or some estimate of when the user can expect the request to be fulfilled with an optional Retry-After header indicating the time the client should wait before querying the service for status. RFC 9110 How do you know it's ready with a 202?
contain the path portion of the URL. Restricting the sub-request to lie within the service domain, mitigating cross-origin security issues and allowing to forward and dispatch the request locally. Security Considerations
a single request MUST NOT include authentication or authorization related HTTP headers, Expect, From, Max-Forwards, Range, or TE headers. If you provide an Authorization header for the outer request, then that header applies to all of the individual calls. Security Considerations (controvertial, see Odata spec vs James Snell's Draft)
a single request MUST NOT include authentication or authorization related HTTP headers, Expect, From, Max-Forwards, Range, or TE headers. If you provide an Authorization header for the outer request, then that header applies to all of the individual calls. When the server receives the batch request, it applies the outer request query parameters and headers (as appropriate) to each part, and then treats each part as if it was a separate HTTP request.
to the mix ➔ I put my ego away and learned that: ➔ You don't always need something new ➔ To better use the platform ➔ To better use the standards ➔ To study and be a critic
gregoirehebert
oracle4engineer
fumiyasac0921
estie
asei
iotengineer22
miu_crescent
sadnessojisan
kniino
tsumita
coincheck_recruit
cmusudakeisuke
tohutohu
colly
cromwellryan
reverentgeek
hannesfritz
holman
tanoku
kneath
scottboms
stephaniewalter
geoffreycrofte
garrettdimon
deanohume
