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
I am even considering operating on the algebra itself and changing the way the
implementedByEffect works to accomodate this
So, I think the only way to go is to do like you did. Define your own methods that wrap the existing algebra, and that do their side-effects. But this might need some changes in how the http4s interpreter is defined, since not all types can be interpreter with effectful computations, as you noticed…
maybe a new abstract type member that captures the effect on encoding?
then what I want would be much easier, overwrite that, add effectful logging and i should be done. might need some annoying machinery though to make this work though
Don't know if this is related, but are there ways in the current algebra to compose different endpoints? For example, we have multiple endpoints that add functionality to an endpoint, such as
One way we thought of is to instantiate and Endpoint to a class like
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): authenticateEndpoint(endpointWithError(versionedEndpoint(...))).One way we thought of is to instantiate and Endpoint to a class like
Endpoints(request: A, response: B, url: String,...) and then "rewrite" these in the interpreters to the corresponding instances (e.g. Route for 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.
23 replies
This message was deleted
What is exactly the use of
def uri in 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
5 replies
@ptrdom Hello, you’re right
ChunkedEntities is 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 ChunkedEntities in the xhr interpreter.
@julienrf Thank you for the reply. I am really interested in having a capability of bidirectional streaming in API.
grpc-web should eventually support this, but there is no clear timeline for client-side streaming support, and protobuf model 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.
@ptrdom That would be a great contribution, although it might require some significant work! By the way, I’ve just found this old attempt at implementing an xhr interpreter for streaming: https://github.com/endpoints4s/endpoints4s/compare/streaming-support#diff-fe8014ca568bf3fc852541330ae13649cf8d4e298abea4ce777f73ddeabd33e2.
I don’t fully remember if eventually I didn’t include it in my final work on streaming because it was not working, or because I didn’t have the resources to finalize the implementations
See also the PR that introduced streaming support, where I give some implementation details: endpoints4s/endpoints4s#465
Coverage dropped by 0,07% :roller_coaster:
Build failed due that reason :see_no_evil:
Hello! I’ve just released endpoints4s 1.4.0 with your latest contributions! https://github.com/endpoints4s/endpoints4s/releases/tag/v1.4.0
It seems that format is not generated for parameters in openapi docs , but it is for request and response body content.
For example, this definition
val foo: Endpoint[(Long, Long, Long), Long] =
endpoint(
request = put(
path / "foo" / segment[Long]("id") /? qs[Long]("long"),
jsonRequest[Long]
),
response = ok(jsonResponse[Long])
)generates parameters without format
"parameters": [
{
"name": "id",
"in": "path",
"schema": {
"type": "integer"
},
"required": true
},
{
"name": "long",
"in": "query",
"schema": {
"type": "integer"
},
"required": true
}
],but request and response body content with format
"content": {
"application/json": {
"schema": {
"type": "integer",
"format": "int64"
}
}
}Is this intended?
Encoding of heterogenous arrays (tuples) in OpenApi docs seems against OpenApi spec.
Example, this definition
val foo: Endpoint[Unit, (String, Long)] =
endpoint(
request = get(path / "foo"),
response = ok(jsonResponse[(String, Long)])
)produces this OpenApi definition for response content (items is an array of SchemaObject)
"content": {
"application/json": {
"schema": {
"type": "array",
"items": [
{
"type": "string"
},
{
"type": "integer",
"format": "int64"
}
]
}
}
}but, OpenApi spec is explicitly against that. In this part, it's stated:
items - Value MUST be an object and not an array. Inline or referenced schema MUST be of a Schema Object and not a standard JSON Schema. items MUST be present if the type is array.
Now, OpenApi 3.0 does not have a proper encoding for heterogenous arrays, unfortunately, afaik.
But the question is, is producing definition against the spec the right choice, or it might be better to produce (not perfectly precise) approximation that conforms spec?
@minedeljkovic I used this source to model the schema of tuples: https://json-schema.org/understanding-json-schema/reference/array.html#tuple-validation but now I learn about
prefixItems. Unfortunately, OpenAPI 3.0 does not support them, as you noticed, so yes, I agree that it is better to produce something else, that conforms to the spec.
Hi @GrafBlutwurst, indeed we didn’t implement it yet. See endpoints4s/endpoints4s#510 We had one issue with the strategy used by the other interpreters
If we fix that issue, we need to update all the other interpreters to be consistent
Would you be interested in contributing to this effort?
Yeah I might have a crack at it, gotta check with my co-workers. But imo it would be the best solution for what we need.