This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to master, this PR will be updated.
Overall, the API based on unnamed objects containing response and request fields
was replaced by more strict and explicit pipeable API which constructs new Api, ApiGroup,
ApiEndpoint, ApiResponse and ApiRequest objects under the hood.
The content field was renamed to body. So on the client side, an endpoint with multiple
responses now returns an object { status; body; headers } instead of { status; content; headers }.
The same on the server side, the handling function shall return the object with a body field
instead of content.
Also, with the new API, the full response is applied only in case the there is a single response
and it specifies headers or if there are multiple responses. So, in case the endpoint changes
the response status, the client now returns the body only.
Multiple responses can be now defined using Api.addResponse / ApiGroup.addResponse combinators. They
accept either a ApiResponse object (constructed using ApiResponse.make) or an object of shape
{ status; body?; headers? }.
The security was one of the reasons to introduce the new API. Previously, the way to declare
an authorization for an endpoint was to specify it in the endpoint options. Now, it is part
of the pipeable API.
Overall, the API based on unnamed objects containing response and request fields
was replaced by more strict and explicit pipeable API which constructs new Api, ApiGroup,
ApiEndpoint, ApiResponse and ApiRequest objects under the hood.
The content field was renamed to body. So on the client side, an endpoint with multiple
responses now returns an object { status; body; headers } instead of { status; content; headers }.
The same on the server side, the handling function shall return the object with a body field
instead of content.
Also, with the new API, the full response is applied only in case the there is a single response
and it specifies headers or if there are multiple responses. So, in case the endpoint changes
the response status, the client now returns the body only.
Multiple responses can be now defined using Api.addResponse / ApiGroup.addResponse combinators. They
accept either a ApiResponse object (constructed using ApiResponse.make) or an object of shape
{ status; body?; headers? }.
The security was one of the reasons to introduce the new API. Previously, the way to declare
an authorization for an endpoint was to specify it in the endpoint options. Now, it is part
of the pipeable API.
This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to master, this PR will be updated.
Releases
effect-http@0.59.0
Minor Changes
#482
4883b71
Thanks @sukovanej! - ## New pipeable APIOverall, the API based on unnamed objects containing
response
andrequest
fields was replaced by more strict and explicit pipeable API which constructs newApi
,ApiGroup
,ApiEndpoint
,ApiResponse
andApiRequest
objects under the hood.Before
After
Multiple-response endpoints changes
The
content
field was renamed tobody
. So on the client side, an endpoint with multiple responses now returns an object{ status; body; headers }
instead of{ status; content; headers }
. The same on the server side, the handling function shall return the object with abody
field instead ofcontent
.Also, with the new API, the full response is applied only in case the there is a single response and it specifies headers or if there are multiple responses. So, in case the endpoint changes the response status, the client now returns the body only.
Multiple responses can be now defined using
Api.addResponse
/ApiGroup.addResponse
combinators. They accept either aApiResponse
object (constructed usingApiResponse.make
) or an object of shape{ status; body?; headers? }
.Security
The security was one of the reasons to introduce the new API. Previously, the way to declare an authorization for an endpoint was to specify it in the endpoint options. Now, it is part of the pipeable API.
effect-http-node@0.7.0
Minor Changes
#482
4883b71
Thanks @sukovanej! - ## New pipeable APIOverall, the API based on unnamed objects containing
response
andrequest
fields was replaced by more strict and explicit pipeable API which constructs newApi
,ApiGroup
,ApiEndpoint
,ApiResponse
andApiRequest
objects under the hood.Before
After
Multiple-response endpoints changes
The
content
field was renamed tobody
. So on the client side, an endpoint with multiple responses now returns an object{ status; body; headers }
instead of{ status; content; headers }
. The same on the server side, the handling function shall return the object with abody
field instead ofcontent
.Also, with the new API, the full response is applied only in case the there is a single response and it specifies headers or if there are multiple responses. So, in case the endpoint changes the response status, the client now returns the body only.
Multiple responses can be now defined using
Api.addResponse
/ApiGroup.addResponse
combinators. They accept either aApiResponse
object (constructed usingApiResponse.make
) or an object of shape{ status; body?; headers? }
.Security
The security was one of the reasons to introduce the new API. Previously, the way to declare an authorization for an endpoint was to specify it in the endpoint options. Now, it is part of the pipeable API.
Patch Changes
4883b71
]: