Rejection created by the various pekko.http.javadsl.server.directives.SecurityDirectives. Signals that the request was rejected because the user could not be authenticated. The reason for the rejection is specified in the cause.

Rejection created by the 'authorize' directive. Signals that the request was rejected because the user is not authorized.

Rejection created by the onCompleteWithBreaker directive. Signals that the request was rejected because the supplied circuit breaker is open and requests are failing fast.

Handles exceptions by turning them into routes. You can create an exception handler in Java code like the following example:

    ExceptionHandler myHandler = ExceptionHandler.of (ExceptionHandler.newPFBuilder()
        .match(IllegalArgumentException.class, x -> Directives.complete(StatusCodes.BAD_REQUEST))
        .build()
    ));

Rejection created when a websocket request was expected but none was found.

Rejection created by pekko.http.scaladsl.server.directives.HeaderDirectives.checkSameOrigin. Signals that the request was rejected because Origin header value is invalid.

Rejection created by parameter filters. Signals that the request was rejected because a query parameter value was not equal to required one.

Rejection created by form field filters. Signals that the request was rejected because a form field could not be interpreted.

Rejection created by header directives. Signals that the request was rejected because a header value is malformed.

Rejection created by parameter filters. Signals that the request was rejected because a query parameter could not be interpreted.

Rejection created by unmarshallers. Signals that the request was rejected because unmarshalling failed with an error that wasn't an IllegalArgumentException. Usually that means that the request content was not of the expected format. Note that semantic issues with the request content (e.g. because some parameter was out of range) will usually trigger a ValidationRejection instead.

Rejection created by method filters. Signals that the request was rejected because the HTTP method is unsupported.

Rejection created by attribute directives. Signals that the request was rejected because a required request attribute could not be found.

Rejection created by the cookie directive. Signals that the request was rejected because a cookie was not found.

Rejection created by form field filters. Signals that the request was rejected because a form field was not found.

Rejection created by header directives. Signals that the request was rejected because a required header could not be found.

Rejection created by parameter filters. Signals that the request was rejected because a query parameter was not found.

A PathMatcher tries to match a prefix of a given string and returns either a PathMatcher.Matched instance if matched, otherwise PathMatchers.Unmatched.

It is not possible to append more matchers with keeping their values as parameters (due to limit of Tuple22).

A PathMatcher tries to match a prefix of a given string and returns either a PathMatcher.Matched instance if matched, otherwise PathMatchers.Unmatched.

It is not possible to append more matchers with keeping their values as parameters (due to limit of Tuple22).

A rejection encapsulates a specific reason why a Route was not able to handle a request. Rejections are gathered up over the course of a Route evaluation and finally converted to pekko.http.scaladsl.model.HttpResponses by the handleRejections directive, if there was no way for the request to be completed.

If providing custom rejections, extend CustomRejection instead.

A Throwable wrapping a Rejection. Can be used for marshalling Future[T] or Try[T] instances, whose failure side is supposed to trigger a route rejection rather than an Exception that is handled by the nearest ExceptionHandler. (Custom marshallers can of course use it as well.)

Rejection created by unmarshallers. Signals that the request was rejected because an message body entity was expected but not supplied.

In the Java DSL, a Route can only consist of combinations of the built-in directives. A Route can not be instantiated directly.

However, the built-in directives may be combined methods like:

Route myDirective(String test, Supplier inner) {
  return
    path("fixed", () ->
      path(test),
        inner
      )
    );
}

The above example will invoke [inner] whenever the path "fixed/{test}" is matched, where "{test}" is the actual String that was given as method argument.

Rejection created by scheme filters. Signals that the request was rejected because the Uri scheme is unsupported.

Rejection created by range directives. Signals that the request contains too many ranges. An irregular high number of ranges indicates a broken client or a denial of service attack.

A special Rejection that serves as a container for a transformation function on rejections. It is used by some directives to "cancel" rejections that are added by later directives of a similar type.

Consider this route structure for example:

put { reject(ValidationRejection("no") } ~ get { ... }

If this structure is applied to a PUT request the list of rejections coming back contains three elements:

1. A ValidationRejection 2. A MethodRejection 3. A TransformationRejection holding a function filtering out the MethodRejection

so that in the end the RejectionHandler will only see one rejection (the ValidationRejection), because the MethodRejection added by the get directive is canceled by the put directive (since the HTTP method did indeed match eventually).

Rejection created by marshallers. Signals that the request was rejected because the service is not capable of producing a response entity whose content type is accepted by the client

Rejection created by encoding filters. Signals that the request was rejected because the service is not capable of producing a response entity whose content encoding is accepted by the client

Rejection created by range directives. Signals that the request was rejected because the requests contains only unsatisfiable ByteRanges. The actualEntityLength gives the client a hint to create satisfiable ByteRanges.

Rejection created by unmarshallers. Signals that the request was rejected because the requests content-type is unsupported.

Rejection created by decoding filters. Signals that the request was rejected because the requests content encoding is unsupported.

Rejection created when a websocket request was not handled because none of the given subprotocols was supported.

Rejection created by the validation directive as well as for IllegalArgumentExceptions thrown by domain model constructors (e.g. via require). It signals that an expected value was semantically invalid.

DEPRECATED, consider https://github.com/theiterators/pekko-http-quickstart-java.g8 instead

Bootstrap trait for Http Server. It helps booting up an pekko-http server by only defining the desired routes. It offers additional hooks to modify the default behavior.