@julienrf I think I found a fairly simple solution for the trailing slash feature. I've created a draft PR to demonstrate it: endpoints4s/endpoints4s#742
Please let me know if this is the right direction (some tests will still fail because it involves changing the interpreters for the
Urls algebra). The idea is that you can simply add a slash to a path like this:
endpoint( method = Get, url = path / segment() / "", response = textResponse, )
I like this because it's intuitive and idiomatic to endpoints' URL DSL. What do you think?
/). In REST endpoints it's not uncommon to accept both trailing and no trailing slash endpoints and let one redirect to the other. Do you think it's sensible to somehow build this into endpoints4s for ease of use?
EndpointsTestApiI noticed that some endpoints are only used in the server and some in the client test suites (e.g.
client.EndpointsTestSuite. I actually expected that all endpoints would be used in all tests, or might I be missing something?
BuiltInErrorsfor a possible extension of the algebra and noticed that while the algebra is content type independent, the various interpreters always implement its methods with the
application/jsoncontent type. My thought then was: wouldn't it be better to use
JsonEntitiesfor this to prevent repeating this pattern? It occurred to me that the reason might be because you then had to mix in
BuiltInErrorsand the latter is used in all the
Endpointsinterpreters it would enforce a possibly unwanted dependency on the user. Is that correct or is there some other reason?
/api/v1/users) or vice-versa. This is often done with APIs to make the endpoints more discoverable (not fail on a single slash). Both use cases can be implemented in pure server code of course, but I think it would be cool to use the clean interface of endpoints4s for this if possible. What do you think?
handleClientErrorsonly gets an instance of
handleClientErrorsto receive more information about the underlying request
The way i did that right now is by having an intermediate trait with
protected def authenticatedRequest[UrlP, BodyP, Out]( method: Method, url: Url[UrlP], entity: RequestEntity[BodyP] )(implicit tuplerUB: Tupler.Aux[UrlP, BodyP, Out] ): Request[ApiEndpoints.AuthenticatedMessage[Out]]
and that works fine for requests. but one of the issues of response logging is that the process of encoding a response is not effectful
implementedByEffectworks to accomodate this
authenticatedEndpoint[A, B]: Endpoint[A, Either[AuthError], B],
endpointWithError[A, B]: Endpoint[A, Either[ClientError, B]]and
versionedEndpoint[A, B](version: ApiVersion): Endpoint[A, B]. Because the Endpoint type is abstract, I cannot find a way to compose these like (pseudo-code):
Endpoints(request: A, response: B, url: String,...)and then "rewrite" these in the interpreters to the corresponding instances (e.g.
Routefor Akka HTTP server or
A => Future[B]for client). But I have a feeling this would involve a pretty fundamental change to the algebras so I'm certainly open to other ideas.
def uriin the Akka HTTP interpreter? It doesn't seem to be used in any code, except via-via in a single line in one test. Could it be possible that the function is not needed? https://github.com/endpoints4s/endpoints4s/blob/master/akka-http/server/src/main/scala/endpoints4s/akkahttp/server/Endpoints.scala#L50
ChunkedEntitiesis not supported by
endpoints.xhr. I don’t remember why I didn’t include it, to be honest. I also remember that I created #287 when I was working on it, so maybe I faced some limitations when trying to implement
ChunkedEntitiesin the xhr interpreter.
grpc-webshould eventually support this, but there is no clear timeline for client-side streaming support, and
protobufmodel does seem unnecessarily limiting for traditional web API, compared to JSON. It would be an interesting endeavor to implement endpoints4s/endpoints4s#287, maybe I could give it a shot.