-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Derive http endpoints from hints #41
Conversation
This derives the HttpEndpoint instance associated to an Endpoint, by searching smithy.api.Http in the the Endpoint's hints, and compiling the found data to the correct interface, by means of Schematic. The rationale is the following : 1. allow for dynamically instantiated service to have HttpService without any bespoke processing. 2. open the door for splitting the http package away from the core module
with schematic.StubSchematic[PathEncode.Make] { | ||
|
||
def default[A]: PathEncode.Make[A] = PathEncode.Make.noop | ||
def document: PathEncode.Make[Document] = PathEncode.Make.noop |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
redundant entry?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nah, the StubSchematic
is not smithy specific (we should have one really), but Document is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but we do have one, smithy4s.StubSchematic
is a thing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hah, forgot about it. Thanks !
|
||
object PathParsingSpec extends weaver.FunSuite { | ||
|
||
test("Parse path pattern into path segments") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's worth having a unit test that verifies how a specific operation encodes to a HttpEndpoint. And maybe a couple examples for paths alone
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For sure. Not sure I'll have much time this week (I already spent much more time on this today than I should have)
modules/core/test/src/smithy4s/http/internals/PathParsingSpec.scala
Outdated
Show resolved
Hide resolved
modules/core/test/src/smithy4s/http/internals/PathParsingSpec.scala
Outdated
Show resolved
Hide resolved
* Derive HttpEndpoint from Hint instead of relying on subtyping This derives the HttpEndpoint instance associated to an Endpoint, by searching smithy.api.Http in the the Endpoint's hints, and compiling the found data to the correct interface, by means of Schematic. The rationale is the following : 1. allow for dynamically instantiated service to have HttpService without any bespoke processing. 2. open the door for splitting the http package away from the core module Also : * AlsRemove uri-specific methods from core package object * Fix URIEncoderDecoder to actually do uri encoding Co-authored-by: Jakub Kozłowski <[email protected]>
Derive HttpEndpoint from Hint instead of relying on subtyping
This derives the HttpEndpoint instance associated to an Endpoint, by searching smithy.api.Http in the the Endpoint's hints, and compiling the found data to the correct interface, by means of Schematic.
The rationale is the following :