Stripe form body support - #34
Merged
Merged
Conversation
…ity; add Client-Tests package
Stripe's v1 API (the part ApptiveAccount currently uses) is entirely
application/x-www-form-urlencoded, but OAOperation>>applyBody:builder:
always looked up 'application/json' regardless of what the operation
actually declares. Added OARequestBody>>preferredContentType (prefers
form-urlencoded, falls back to json, else whatever is there) and
OAMediaTypeObject>>writeFormBody:builder: as the form-writing counterpart
to the existing JSON writer; applyBody:builder: now picks the writer to
match.
Also, while driving real requests through OpenApiClient against the
Stripe spec + stripe-mock:
- OAMediaTypeObject was missing #encoding: - its own NeoJSON mapping
declares an accessor pair for #encoding but only the getter existed,
so parsing any spec using the OpenAPI "encoding" keyword crashed.
- JSONSchemaAnyObject had no #acceptOpenApi: at all (unlike Object/Array,
which at least have the recurse-later stub) - hit by Stripe's metadata
schemas, which collapse to an any-type schema.
- OpenApiClient>>operation:arguments:body:beforeSendDo: calls
#handleError:request:response: but only a 2-arg #handleError:response:
was defined, so any non-2xx response crashed with doesNotUnderstand
instead of raising the intended OAUnspecifiedError.
Also fixes OARequestBuilder>>flattenFormParameters:prefix:into: (from the
prior commit) to recognize OrderedDictionary, not just Dictionary -
schema-validated request bodies are read back as NeoJSONObject, which
subclasses OrderedDictionary and does NOT inherit from Dictionary in
Pharo, so it was silently falling through to the scalar branch and
serializing the whole object as one bogus nil-keyed field.
Added the OpenAPI-Client-Tests package (did not exist before - Client had
zero test coverage) with OARequestBuilderTest covering the flatten
function (scalars, nested Dictionary, nested OrderedDictionary/
NeoJSONObject, arrays of objects, deep nesting) and addFormBody:.
All of this was found and verified by actually loading the real Stripe
OpenAPI spec (spec3.json) and driving requests through a live stripe-mock
instance - not just reasoning about the code. POST /v1/customers, DELETE
/v1/customers/{customer} (full round trip), and POST /v1/subscriptions
with nested items[0][price] bracket-notation all build and send
correctly now. Response-body reading for the full Customer/Subscription
response schemas still hits separate, deeper issues (nullable is not
threaded through nested property schemas at all - see the JSONSchema
fixes commit - and likely more undiscovered gaps); that is left for a
follow-up rather than solved here.
…ed explicit Iceberg registration)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.