@@ -15,34 +15,31 @@ See this test for the [serialization behavior](./test/serialization.test.ts).
1515
1616[ URLSearchParams ] : https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams
1717
18- ## Motivation
19-
20- URL search parameters are strings, however the Seam API will parse parameters as complex types.
21- The Seam SDK must accept the complex types as input and serialize these
22- to search parameters in a way supported by the Seam API.
23-
24- There is no single standard for this serialization.
25- This module establishes the serialization standard adopted by the Seam API.
26-
27- ### Why not use [ URLSearchParams] ( https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams ) ?
28-
29- - Passing a raw object to URLSearchParams has unpredictable serialization behavior.
30-
31- ### Why not [ qs] ( https://github.com/ljharb/qs ) ?
32-
33- - Not a zero-dependency module. Has quite a few dependency layers.
34- - Impractile as a reference implementation.
35- qs enables complex, non-standard parsing and serialization,
36- which makes ensuing SDK parity much harder.
37- Similarly, this puts an unreasonable burden on user's of the HTTP API or those implementing their own client.
38- - The Seam API must ensure it handles a well defined set of non-string query parameters consistency.
39- Using qs would allow the SDK to send unsupported or incorrectly serialized parameter types to the API
40- resulting in unexpected behavior.
41-
42- ### Why not use the default [ Axios] ( https://axios-http.com/ ) serializer?
43-
44- - Using the default [ Axios] serializer was the original approach,
45- however it had similar issues to using URLSearchParams and qs as noted above.
18+ ### Serialization strategy
19+
20+ Serialization uses
21+ [ ` URLSearchParams.toString() ` ] ( https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/toString#return_value )
22+ which encodes most non-alphanumeric characters.
23+
24+ - The primitive types ` string ` , ` number ` , and ` bigint ` are serialized using ` .toString() ` .
25+ - The primitive ` boolean ` type is serialized using ` .toString() ` to ` 'true' ` or ` 'false' ` .
26+ - The primitive ` null ` and ` undefined ` values are removed,
27+ e.g., ` { foo: null, bar: undefined, baz: 1 } ` serializes to ` baz=1 ` .
28+ - ` Date ` objects are detected and serialized using ` Date.toISOString() ` .
29+ - ` Temporal.Instant ` objects are detected and serialized by first converting them to ` Date `
30+ and then serializing the ` Date ` as above.
31+ - Arrays are serialized using
32+ [ ` URLSearchParams.append() ` ] ( https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/append ) :
33+ - Array values are serialized as above.
34+ - The array ` { foo: [1, 2] } ` serializes to ` foo=1&foo=2 ` .
35+ - The single element array ` { foo: [1] } ` serializes to ` foo=1 ` .
36+ - The empty array ` { foo: [] } ` serializes to ` foo= ` .
37+ - Serialization of the single element array containing the empty string is not supported
38+ and will throw an ` UnserializableParamError ` .
39+ Otherwise, the serialization of ` { foo: [''] } ` would conflict with ` { foo: [] } ` .
40+ This serializer chooses to support the more common and more useful case of an empty array.
41+ - Serialization of functions or other objects is not supported
42+ and will throw an ` UnserializableParamError ` .
4643
4744## Installation
4845
@@ -111,6 +108,35 @@ const { data } = await client.get('/search', {
111108
112109[ Axios ] : https://axios-http.com/
113110
111+ ## Motivation
112+
113+ URL search parameters are strings, however the Seam API will parse parameters as complex types.
114+ The Seam SDK must accept the complex types as input and serialize these
115+ to search parameters in a way supported by the Seam API.
116+
117+ There is no single standard for this serialization.
118+ This module establishes the serialization standard adopted by the Seam API.
119+
120+ ### Why not use [ URLSearchParams] ( https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams ) ?
121+
122+ - Passing a raw object to URLSearchParams has unpredictable serialization behavior.
123+
124+ ### Why not [ qs] ( https://github.com/ljharb/qs ) ?
125+
126+ - Not a zero-dependency module. Has quite a few dependency layers.
127+ - Impractical as a reference implementation.
128+ qs enables complex, non-standard parsing and serialization,
129+ which makes ensuing SDK parity much harder.
130+ Similarly, this puts an unreasonable burden on user's of the HTTP API or those implementing their own client.
131+ - The Seam API must ensure it handles a well defined set of non-string query parameters consistency.
132+ Using qs would allow the SDK to send unsupported or incorrectly serialized parameter types to the API
133+ resulting in unexpected behavior.
134+
135+ ### Why not use the default [ Axios] ( https://axios-http.com/ ) serializer?
136+
137+ - Using the default [ Axios] serializer was the original approach,
138+ however it had similar issues to using URLSearchParams and qs as noted above.
139+
114140## Development and Testing
115141
116142### Quickstart
0 commit comments