Closed Fishrock123 closed 4 years ago
great post, i think i agree with this direction. thanks for writing this up!
should we still have surf::post
at all if it's just a shorthand for like, surf::RequestBuilder::post()
? :)
Have
Client::send(req: impl Into<surf::Request>) -> BoxedFuture
rather than making anything be directly await-able.
strongly agree with this in particular—it makes the API a bit less "nice" (for some values of nice) but it's better both for the implementation and for actually modeling how requests are sent (client sends requests, requests don't send themselves).
Done in #194.
This is essentially a summary of the major improvements to Surf I've been trying to make. there is a lot of overlap with disparate existing issues, which I've linked where appropriate.
In order to improve middleware for Surf (https://github.com/http-rs/surf/issues/131), and bring it more in-line with Tide, the following changes should be made:
surf::Request
,surf::Response
rather thanhttp_types::Request
, etc.surf::Request
should be changed to be a more minimalized wrapper aroundhttp_types::Request
(similar toResponse
and Tide.)And also for code hygiene,
Request
should probably not be all of these at once (https://github.com/http-rs/surf/issues/152):Future
Additionally related,
Client
should not be generic (https://github.com/http-rs/surf/issues/69), (comment on 105), and Middleware may want to be accessible from the present Middleware stack for complete retry/redirect purposes (https://github.com/http-rs/surf/issues/169), (https://github.com/http-rs/surf/issues/18).Note: Making
Client
1:1 with an actualizedRequest
helps this but doesn't work forkeep-alive
or http2/3+.There is a clean but slightly less ergonomic way to solve most of the API issues here:
surf::Request
be liketide::Request
, only holdhttp_types::Request
.surf::Request
Client::send(req: impl Into<surf::Request>) -> BoxedFuture
rather than making anything be directly await-able.Client
. (https://github.com/http-rs/surf/issues/126)RequestBuilder
similar totide::ResponseBuilder
.RequestBuilder::send()
be a short-cut for "build and make a newClient
and call.send(self)
on it".surf::method()
return aRequestBuilder
.With middleware:
Regarding
Client
being generic,I see two paths. Either #69,or just making the structure's properties be directly determined by compile-time configuration.dyn
is probably better if we want people to be able to pass external clients that implement some kind of trait. In that case,surf::client_from(trait)
or similar could exist, or possibly even.send::<ClientType>()
. Update: see https://github.com/http-rs/surf/pull/193 "dyn HttpClient
". (Merged)Ideally I think that
Client
would be the thing that actualizes/sendsRequest
s and holds the middleware stack, similar to what https://github.com/http-rs/surf/issues/109 asks for.This was an older WIP, see #194 for a full compiling patch of the above proposal!
I have a WIP patch of some of this stuff, but in the form of a `SurfBuilder`, which has a structure like so and is not much cleaner than today, although it does allow middleware to operate on `surf::Request` and `surf::Response`. **I prefer the approach I described above.** ```rust // not great pub struct SurfBuildertl;dr things become much cleaner and simpler if:
surf::method()
returns does not have.middleware()
(@yoshuawuyts?) (https://github.com/http-rs/surf/issues/126)Client
is made. See https://github.com/Fishrock123/surf/pull/1Whateversurf::method()
returns does notimpl Future
. (@yoshuawuyts)IntoFuture
comes would be better...)RequestBuilder
. See https://github.com/http-rs/surf/pull/194Client
is no longer generic. (@goto-bus-stop?, @yoshuawuyts?) (https://github.com/http-rs/surf/issues/69) (https://github.com/http-rs/surf/issues/150)