Adds a new error variant, where the current error output is represented as a Left, and the given one as a Right.

Appends a new error output variant.

A variant for the current endpoint output will be created using the given Tapir.oneOfVariant. This is needed to capture the logic which allows deciding if a run-time value is applicable to a variant. If the erasure of the E type is different from E, there will be a compile-time failure, as no such run-time check is possible. In this case, use errorOutVariantsFromCurrent and create a variant using one of the other variant factory methods (e.g. Tapir.oneOfVariantValueMatcher).

During encoding/decoding, the new o variant will be checked after the current variant.

More specifically, the current error output is replaced with a Tapir.oneOf output, where:

• the first output variant is the current variant: oneOfVariant(errorOutput)
• the second output variant is the given o

Usage example:

sealed trait Parent
case class Child1(v: String) extends Parent
case class Child2(v: String) extends Parent

val e: PublicEndpoint[Unit, Parent, Unit, Any] = endpoint
  .errorOut(stringBody.mapTo[Child1])
  .errorOutVariant[Parent](oneOfVariant(stringBody.mapTo[Child2]))

Adding error output variants is useful when extending the error outputs in a PartialServerEndpoint, created using EndpointServerLogicOps.serverSecurityLogic.

Same as errorOutVariant, but allows appending multiple variants in one go.

Replace the error output with a Tapir.oneOf output, using the variants returned by variants. The current output should be included in one of the returned variants.

Allows creating the variant list in a custom order, placing the current variant in an arbitrary position, and using default variants if necessary.

Adding error output variants is useful when extending the error outputs in a PartialServerEndpoint, created using EndpointServerLogicOps.serverSecurityLogic.

The method defined in a fixed method input in this endpoint, if any (using e.g. EndpointInputsOps.get or EndpointInputsOps.post).

Renders endpoint path, by default all parametrised path and query components are replaced by {param_name} or {paramN}, e.g. for

endpoint.in("p1" / path[String] / query[String]("par2"))

returns /p1/{param1}?par2={par2}

Combine this public endpoint description with a function, which implements the server-side logic. The logic returns a result, which is either an error or a successful output, wrapped in an effect type F. For secure endpoints, use serverSecurityLogic.

A server endpoint can be passed to a server interpreter. Each server interpreter supports effects of a specific type(s).

Both the endpoint and logic function are considered complete, and cannot be later extended through the returned ServerEndpoint value (except for endpoint meta-data). Secure endpoints allow providing the security logic before all the inputs and outputs are specified.

Like serverLogic, but specialised to the case when the result is always an error (Left), hence when the logic type can be simplified to I => F[E].

Like serverLogic, but specialised to the case when the logic function is pure, that is doesn't have any side effects.

Same as serverLogic, but requires E to be a throwable, and coverts failed effects of type E to endpoint errors.

Like serverLogic, but specialised to the case when the result is always a success (Right), hence when the logic type can be simplified to I => F[O].

Combine this endpoint description with a function, which implements the security logic of the endpoint.

Subsequently, the endpoint inputs and outputs can be extended (for error outputs, new variants can be added, but they cannot be arbitrarily extended). Then the main server logic can be provided, given a function which accepts as arguments the result of the security logic and the remaining input. The final result is then a ServerEndpoint.

A complete server endpoint can be passed to a server interpreter. Each server interpreter supports effects of a specific type(s).

An example use-case is defining an endpoint with fully-defined errors, and with security logic built-in. Such an endpoint can be then extended by multiple other endpoints, by specifying different inputs, outputs and the main logic.

Like serverSecurityLogic, but specialised to the case when the result is always an error (Left), hence when the logic type can be simplified to A => F[E].

Like serverSecurityLogic, but specialised to the case when the logic function is pure, that is doesn't have any side effects.

Same as serverSecurityLogic, but requires E to be a throwable, and coverts failed effects of type E to endpoint errors.

Like serverSecurityLogic, but specialised to the case when the result is always a success (Right), hence when the logic type can be simplified to A => F[U].

Basic information about the endpoint, excluding mapping information, with inputs sorted (first the method, then path, etc.)

Detailed description of the endpoint, with inputs/outputs represented in the same order as originally defined, including mapping information.

Equivalent to .toString, shows the whole case class structure.