julienrf on master
Support Scala Native in algebra… Add Native projects to ci.yaml … Update Scala.js to 1.8.0 and 7 more (compare)
julienrf on master
Update scalajs-dom to 2.2.0 (compare)
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
?
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)?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
)
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?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#L64Directives.Segments
says: "If the path has a trailing slash this slash will not be matched."
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/mM7ykeavjsdom
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.
@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?
/
). 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?
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?
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?
/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?
handleClientErrors
only gets an instance of Invalid
?
handleClientErrors
to 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