mirrors/axum-connect
1
0
Fork 0
mirror of https://github.com/AThilenius/axum-connect.git synced 2025-01-06 18:18:42 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Fix a few typos

Browse source
This commit is contained in:
Alec Thilenius 2023-05-29 22:01:18 -07:00
parent 9f017696e5
commit ccbebb8dce
1 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
README.md
View file

@ -150,7 +150,7 @@ curl --location 'http://localhost:3030/hello.HelloWorldService/SayHello' \
From here you can stand up a `connect-web` TypeScript/Go project to call your From here you can stand up a `connect-web` TypeScript/Go project to call your
API with end-to-end typed RPCs. API with end-to-end typed RPCs.
## Request/Response Parts # Request/Response Parts 🙍‍♂️
Both the request and response types are derived in `axum-connect`. This might Both the request and response types are derived in `axum-connect`. This might
seem redundant at first. seem redundant at first.
@ -159,7 +159,7 @@ Let's go over the easier one first, `RpcIntoResponse`. Connect RPCs are not
arbitrary HTML requests, they cannot return arbitrary HTML responses. For arbitrary HTML requests, they cannot return arbitrary HTML responses. For
example, streaming responses MUST return an HTTP 200 regardless of error state. example, streaming responses MUST return an HTTP 200 regardless of error state.
Keeping with Axum's (fantastic) paradigm, that is enforced by the type system. Keeping with Axum's (fantastic) paradigm, that is enforced by the type system.
RPC handler may not return arbitrary HTML, but instead must return something RPC handlers may not return arbitrary HTML, but instead must return something
that `axum-connect` knows how to turn into a valid Connect response. that `axum-connect` knows how to turn into a valid Connect response.
Somewhat less intuitively, `axum-connect` derives `RpcFromRequestParts`, which Somewhat less intuitively, `axum-connect` derives `RpcFromRequestParts`, which
@ -169,14 +169,14 @@ is a problem for the same reason.
Axum also allows a `FromRequest` to occupy the last parameter in a handler which Axum also allows a `FromRequest` to occupy the last parameter in a handler which
consumed the remainder of the HTTP request (including the body). `axum-connect` consumed the remainder of the HTTP request (including the body). `axum-connect`
needs to handle the response input itself, so there is no equivalent for RPCs needs to handle the request input itself, so there is no equivalent for RPCs
handlers. handlers.
# Roadmap / Stated Non-Goals 🛣️ # Roadmap / Stated Non-Goals 🛣️
- Explore better typing that `RpcFromRequestParts` - Explore better typing than `RpcFromRequestParts`
- Ideally clients only need to provide an `RpcIntoError`, but I haven't fully - Ideally clients only need to provide an `RpcIntoError`, but I haven't fully
thought this problem though. I just know that having to specific both a thought this problem through. I just know that having to specific both a
`FromRequestParts` and an `RpcFromRequestParts` on custom types is a PITA. `FromRequestParts` and an `RpcFromRequestParts` on custom types is a PITA.
- Rework error responses to allow for multiple errors - Rework error responses to allow for multiple errors
- Version checking between generated and runtime code - Version checking between generated and runtime code