Endpoint

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 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.

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). To provide the logic in parts, see serverLogicPart and serverLogicForCurrent.

Combine this endpoint description with a function, which implements a part of the server-side logic, for the entire input defined so far. The partial logic returns a result, which is either an error or a success value, wrapped in an effect type F.

Subsequently, the endpoint inputs and outputs can be extended (but not error outputs!). Then, either further parts of the server logic can be provided (again, consuming the whole input defined so far). Or, the entire remaining server logic can be provided, given a function which accepts as arguments the results of applying the part-functions, 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).

When using this method, each logic part consumes the whole input defined so far. To provide the server logic in parts, where only part of the input is consumed (but the endpoint cannot be later extended), see the serverLogicPart function.

An example use-case is defining an endpoint with fully-defined errors, and with authorization logic built-in. Such an endpoint can be then extended by multiple other endpoints.

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

Combine this endpoint description with a function, which implements a part of the server-side logic. The partial logic returns a result, which is either an error or a success value, wrapped in an effect type F.

Subsequent parts of the logic can be provided later using ServerEndpointInParts.andThenPart, consuming successive input parts. Finally, the logic can be completed, given a function which accepts as arguments the results of applying on part-functions, 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).

When using this method, the endpoint description is considered complete, and cannot be later extended through the returned ServerEndpointInParts value. However, each part of the server logic can consume only a part of the input. To provide the logic in parts, while still being able to extend the endpoint description, see serverLogicForCurrent.

An example use-case is providing authorization logic, followed by server logic (using an authorized user), given a complete endpoint description.

Note that the type of the f partial server logic function cannot be inferred, it must be explicitly given (e.g. by providing a function or method value).

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

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

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.