Hello @/all, I have added an “Adopters” section to the README, I would appreciate if you could give me a few organization names I can add to the list :smile: https://github.com/endpoints4s/endpoints4s/blob/master/README.md#adopters
In the routes, I've been using
Either and having it Left(Invalid(...)) on the failure case - noticing that Invalid's the failure case of Validated... wondering if I should be having the routes return Validated instead of Either?
2 replies
So, this is something we could add to the openapi interpreter maybe, and all the server interpreters would benefit from it
I’ve just opened #728 to implement it in the Akka HTTP server interpreter, though
In the error handlers, you have access to the
I'd like to log unexpected Throwables, but was thinking it'd also be nice to log the request that lead to that exception being thrown...
Throwable... I'm wondering if there's a spot that has access to both that Throwable, and the request (at least the name of the endpoint that was called)?I'd like to log unexpected Throwables, but was thinking it'd also be nice to log the request that lead to that exception being thrown...
Hey @/all, I have just cut a new release: https://github.com/endpoints4s/endpoints4s/releases/tag/v1.3.0 thank you all for your contributions!
Hi, does anyone know if it is possible to define an endpoint with a url that ends with a slash (or optional slash)? I tried the following but it still gave a 404 on
localhost/foo/ (but not on localhost/foo):endpoint(
method = Get,
url = path / segment[String]() / "",
response = textResponse,
)@agboom I think this use case is not covered at the moment. You may want to introduce something like the following:
def trailingSlash[A](path: Path[A]): Path[A]Which you could use as follows:
endpoint(
method = Get,
url = trailingSlash(path / segment[String]()),
response = textResponse
)
And you would have to figure out the implementations for server, client, and openapi interpreters, according to your usage
Let me know if you need more help
I'm looking into the Akka HTTP server interpreters and was wondering: what's the thought behind
Link to code: https://github.com/endpoints4s/endpoints4s/blob/154e7ce630f284056f8c9ba3d8f302e326c9d696/akka-http/server/src/main/scala/endpoints4s/akkahttp/server/Urls.scala#L23
Path.validateUrl calling Url.validate? It seems that only the path passed to validateUrl is actually validated, but the query is ignored. Is that intentional?Link to code: https://github.com/endpoints4s/endpoints4s/blob/154e7ce630f284056f8c9ba3d8f302e326c9d696/akka-http/server/src/main/scala/endpoints4s/akkahttp/server/Urls.scala#L23
3 replies
Also: I think the (optional) trialing slash I'm trying to implement will involve a change in
The Scaladoc string of
Url.directive in the server interpreter, because Directive.Segments does not match trailing slashes: https://github.com/endpoints4s/endpoints4s/blob/154e7ce630f284056f8c9ba3d8f302e326c9d696/akka-http/server/src/main/scala/endpoints4s/akkahttp/server/Urls.scala#L64The Scaladoc string of
Directives.Segments says: "If the path has a trailing slash this slash will not be matched."
2 replies
If I run
In short, there's a timezone error (probably because of the tz config on my local machine?), a ServerListenException on port 9000 (I checked if the port was in use, but it wasn't) and a generic Exception with "Something went wrong" followed by a dead letter warning (but that appears to be part of testing the exception flow, so that's expected)
sbt test on the latest commit, some tests appear to fail (only due to exceptions, not assertions). Is that expected behavior? Here are the logs: https://pastebin.com/mM7ykeavIn short, there's a timezone error (probably because of the tz config on my local machine?), a ServerListenException on port 9000 (I checked if the port was in use, but it wasn't) and a generic Exception with "Something went wrong" followed by a dead letter warning (but that appears to be part of testing the exception flow, so that's expected)
@agboom, the JS tests need
jsdom to be installed locally ($ npm install jsdom). The ServerListenException is not expected, and I think we also get it spuriously on the CI, so this is something we need to fix, and the “Something went wrong” is not an actual test failure, it’s part of the expected test execution.
1 reply
@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[String]() / "",
response = textResponse,
)I like this because it's intuitive and idiomatic to endpoints' URL DSL. What do you think?
3 replies
I'd also like to explore ways to create endpoints that accept both a trailing slash and no trailing slash (an optional
/). 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?
While adding to the
EndpointsTestApi I noticed that some endpoints are only used in the server and some in the client test suites (e.g. deleteEndpoint only in server.EndpointsTestSuite and optionalEndpoint only in client.EndpointsTestSuite. I actually expected that all endpoints would be used in all tests, or might I be missing something?
2 replies
Hi, I was looking at
BuiltInErrors for 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/json content type. My thought then was: wouldn't it be better to use jsonResponse from JsonEntities for this to prevent repeating this pattern? It occurred to me that the reason might be because you then had to mix in JsonEntities in BuiltInErrors and the latter is used in all the Endpoints interpreters it would enforce a possibly unwanted dependency on the user. Is that correct or is there some other reason?
3 replies
Sorry for asking all these questions, but I have another one (please tell me if I need to stop :see_no_evil:). Did you at one time consider to add support for redirect endpoints? Currently, I need to explicitly add any redirect url to the server implementation. This feels somewhat awkward and of course the documentation or client support is left out. On the other hand, I can imagine that it's kind of a niche use case. When would you want to document redirects with OpenAPI, or support it in a client? In my case I have a server that is both a JSON API and an HTML staticfile server, of which the latter has redirects. For simplicity and clarity I'd like to define both with endpoints4s. I guess that's kind of a use case, be it a niche one. Another use case I can think of is API endpoints redirecting trailing slashes to no trailing slashes (e.g.
/api/v1/users/ to /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?
22 replies
but isn't it an issue of the algebra because
handleClientErrors only gets an instance of Invalid ?
But I agree that it seems impossible to know the route that failed from there
(ftr, the equivalent method in the akka-http interpreter does provide a way to retrieve the underlying route)
So, in the case of the http4s server, I agree that we should change the signature of
handleClientErrors to receive more information about the underlying request
that being Java 15.0.1 do we need that flag?
endpoints4s/endpoints4s#755 done. yeah i threw out the VM arg. I think it's a common flag for SBT speedup but it works just fine without it.
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