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
implementedByEffect
works 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): authenticateEndpoint(endpointWithError(versionedEndpoint(...)))
.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.
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
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.
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.
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?
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.