Introduce URIEncoder and URIDecoder types #41
Merged
Conversation
This file contains 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
|
This looks great! I think it's flexible enough to use wherever. Do you think we should support percent encoding from the beginning? I can see a lot of things breaking if you included a literal |
Ah yes, I didn't mention this in the PR description - this doesn't do any percent escaping yet, I first wanted to get feedback on the architecture. I'll add escaping etc before moving this into proper review. |
…now, no nested containers, as per the RFCs
|
@bfrearson Ok so I got it all working end to end now, without nesting (that's a future enhancement) - WDYT? This isn't polished yet, but tests are passing. |
czechboy0
commented
Aug 23, 2023
bfrearson
suggested changes
Aug 24, 2023
Sources/OpenAPIRuntime/URICoder/Common/URICoderConfiguration.swift
Outdated
Show resolved
Hide resolved
czechboy0
changed the title
This was referenced Aug 25, 2023
czechboy0
added a commit
that referenced
this pull request
Aug 29, 2023
Introduce StringEncoder and StringDecoder types ### Motivation A sibling PR to #41, as part of moving from hand-crafted code that uses `LosslessStringConvertible` conformances on built-in and generated types, we need not just an URI coder, but also a raw string coder. This will be used for encoding and decoding `text/plain` bodies, where only primitive types can be used, and are encoded as raw strings. ### Modifications Introduced two types, `StringEncoder` and `StringDecoder`. It's very simple, doesn't support containers, only primitive types. ### Result Once this lands, it'll allow us to get rid of our ugly marker protocols `_StringConvertible` and `_AutoLosslessStringConvertible` and always go through `Codable`. More on this in subsequent PRs integrating this logic. ### Test Plan Added a rountrip unit test. Reviewed by: glbrntt Builds: ✔︎ pull request validation (5.8) - Build finished. ✔︎ pull request validation (5.9) - Build finished. ✔︎ pull request validation (api breakage) - Build finished. ✔︎ pull request validation (docc test) - Build finished. ✔︎ pull request validation (integration test) - Build finished. ✔︎ pull request validation (nightly) - Build finished. ✔︎ pull request validation (soundness) - Build finished. #44
czechboy0
added a commit
to apple/swift-openapi-generator
that referenced
this pull request
Aug 30, 2023
[Generator] Integrate the new URI and String coders ### Motivation Depends on runtime changes from apple/swift-openapi-runtime#45. Up until now, we relied on a series of marker and helper protocols `_StringConvertible` and `_AutoLosslessStringConvertible` to handle converting between various types and their string representation. This has been very manual and required a non-trivial amount of work to support any extra type, especially `Date` and generated string enums. Well, turns out this was an unnecessarily difficult way to approach the problem - we had a better solution available for a long time - `Codable`. Since all the generated types and all the built-in types we reference are already `Codable`, there is no need to reinvent a way to serialize and deserialize types, and we should just embrace it. While a JSON encoder and decoder already exists in Foundation, we didn't have one handy for encoding to and from URIs (used by headers, query and path parameters), and raw string representation (using `LosslessStringConvertible`). We created those in the runtime library in PRs apple/swift-openapi-runtime#44 and apple/swift-openapi-runtime#41, and integrated them into our helper functions (which got significantly simplified this way) in apple/swift-openapi-runtime#45. Out of scope of this PR, but this also opens the door to supporting URL form encoded bodies (#182), multipart (#36), and base64 (#11). While this should be mostly invisible to our adopters, this refactoring creates space for implementing more complex features and overall simplifies our serialization story. ### Modifications - Updated the generator to use the new helper functions. - Updated the article about serialization, shows how we reduced the number of helper functions by moving to `Codable`. - Set the `lineLength` to 120 on the formatter configuration, it was inconsistent with our `.swift-format` file, and lead to the soundness script trying to update the reference files, but then the reference tests were failing. Since we're planning to sync these in #40, this is a step closer to it, but it means that it's probably best to review this PR's diff with whitespace ignored. ### Result Now the generated code uses the new helper functions, allowing us to delete all the deprecated helpers in 0.2.0. ### Test Plan Updated file-based reference, snippet, and unit tests. Reviewed by: glbrntt Builds: ✔︎ pull request validation (5.8) - Build finished. ✔︎ pull request validation (5.9) - Build finished. ✔︎ pull request validation (docc test) - Build finished. ✔︎ pull request validation (integration test) - Build finished. ✔︎ pull request validation (nightly) - Build finished. ✔︎ pull request validation (soundness) - Build finished. #226
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Motivation
Fixes apple/swift-openapi-generator#192.
For refactoring how we encode:
application/x-www-form-urlencodedbodiesSupports:
Modifications
First step - introduce two new types:
URIEncoderandURIDecoder.They're configurable types that can handle the URI Template (RFC 6570) form and simple styles, refined by OpenAPI 3.0.3, and also the
application/x-www-form-urlencodedformat (mostly identical to URI Template).Result
The types can be used now, subsequent PRs will integrate them.
Test Plan
Added unit tests for the individual parts of the coder, but also roundtrip tests.