Operations on an endpoint receive input via their parameters. When exposed via the web, the values for these parameters are taken from the URL’s query parameters and from the JSON request body. When exposed via JMX, the parameters are mapped to the parameters of the MBean’s operations. Parameters are required by default. They can be made optional by annotating them with @org.springframework.lang.Nullable .

Each root property in the JSON request body can be mapped to a parameter of the endpoint. Consider the following JSON request body:

{
	"name": "test",
	"counter": 42
}

This can be used to invoke a write operation that takes String name and int counter parameters.

	Tip
	Because endpoints are technology agnostic, only simple types can be specified in the method signature. In particular declaring a single parameter with a custom type defining a name and counter properties is not supported.

	Note
	To allow the input to be mapped to the operation method’s parameters, Java code implementing an endpoint should be compiled with -parameters , and Kotlin code implementing an endpoint should be compiled with -java-parameters . This will happen automatically if you are using Spring Boot’s Gradle plugin or if you are using Maven and spring-boot-starter-parent .

Operations on an @Endpoint , @WebEndpoint , or @EndpointWebExtension are automatically exposed over HTTP using Jersey, Spring MVC, or Spring WebFlux.

Web Endpoint Range Requests

An HTTP range request can be used to request part of an HTTP resource. When using Spring MVC or Spring Web Flux, operations that return a org.springframework.core.io.Resource automatically support range requests.

	Note
	Range requests are not supported when using Jersey.

A Servlet can be exposed as an endpoint by implementing a class annotated with @ServletEndpoint that also implements Supplier<EndpointServlet> . Servlet endpoints provide deeper integration with the Servlet container but at the expense of portability. They are intended to be used to expose an existing Servlet as an endpoint. For new endpoints, the @Endpoint and @WebEndpoint annotations should be preferred whenever possible.

@ControllerEndpoint and @RestControllerEndpoint can be used to implement an endpoint that is only exposed by Spring MVC or Spring WebFlux. Methods are mapped using the standard annotations for Spring MVC and Spring WebFlux such as @RequestMapping and @GetMapping , with the endpoint’s ID being used as a prefix for the path. Controller endpoints provide deeper integration with Spring’s web frameworks but at the expense of portability. The @Endpoint and @WebEndpoint annotations should be preferred whenever possible.

The following HealthIndicators are auto-configured by Spring Boot when appropriate:

	Tip
	You can disable them all by setting the management.health.defaults.enabled property.

To provide custom health information, you can register Spring beans that implement the HealthIndicator interface. You need to provide an implementation of the health() method and return a Health response. The Health response should include a status and can optionally include additional details to be displayed. The following code shows a sample HealthIndicator implementation:

import org.springframework.boot.actuate.health.Health;
import org.springframework.boot.actuate.health.HealthIndicator;
import org.springframework.stereotype.Component;
@Component
public class MyHealthIndicator implements HealthIndicator {
	@Override
	public Health health() {
		int errorCode = check(); // perform some specific health check
		if (errorCode != 0) {
			return Health.down().withDetail("Error Code", errorCode).build();
		return Health.up().build();
}

	Note
	The identifier for a given HealthIndicator is the name of the bean without the HealthIndicator suffix, if it exists. In the preceding example, the health information is available in an entry named my .

In addition to Spring Boot’s predefined Status types, it is also possible for Health to return a custom Status that represents a new system state. In such cases, a custom implementation of the HealthAggregator interface also needs to be provided, or the default implementation has to be configured by using the management.health.status.order configuration property.

For example, assume a new Status with code FATAL is being used in one of your HealthIndicator implementations. To configure the severity order, add the following property to your application properties:

management.health.status.order=FATAL, DOWN, OUT_OF_SERVICE, UNKNOWN, UP

The HTTP status code in the response reflects the overall health status (for example, UP maps to 200, while OUT_OF_SERVICE and DOWN map to 503). You might also want to register custom status mappings if you access the health endpoint over HTTP. For example, the following property maps FATAL to 503 (service unavailable):

management.health.status.http-mapping.FATAL=503

	Tip
	If you need more control, you can define your own HealthStatusHttpMapper bean.

The following table shows the default status mappings for the built-in statuses:

For reactive applications, such as those using Spring WebFlux, ReactiveHealthIndicator provides a non-blocking contract for getting application health. Similar to a traditional HealthIndicator , health information is collected from the content of a ReactiveHealthIndicatorRegistry (by default all HealthIndicator and ReactiveHealthIndicator instances defined in your ApplicationContext . Regular HealthIndicator that do not check against a reactive API are executed on the elastic scheduler.

	Tip
	In a reactive application, The ReactiveHealthIndicatorRegistry can be used to register and unregister health indicators at runtime.

To provide custom health information from a reactive API, you can register Spring beans that implement the ReactiveHealthIndicator interface. The following code shows a sample ReactiveHealthIndicator implementation:

@Component
public class MyReactiveHealthIndicator implements ReactiveHealthIndicator {
	@Override
	public Mono<Health> health() {
		return doHealthCheck() //perform some specific health check that returns a Mono<Health>
			.onErrorResume(ex -> Mono.just(new Health.Builder().down(ex).build())));
}

	Tip
	To handle the error automatically, consider extending from AbstractReactiveHealthIndicator .

The following ReactiveHealthIndicators are auto-configured by Spring Boot when appropriate:

	Tip
	If necessary, reactive indicators replace the regular ones. Also, any HealthIndicator that is not handled explicitly is wrapped automatically.

The following InfoContributor beans are auto-configured by Spring Boot, when appropriate:

	Tip
	It is possible to disable them all by setting the management.info.defaults.enabled property.

You can customize the data exposed by the info endpoint by setting info.* Spring properties. All Environment properties under the info key are automatically exposed. For example, you could add the following settings to your application.properties file:

info.app.encoding=UTF-8
info.app.java.source=1.8
info.app.java.target=1.8

	Tip
	Rather than hardcoding those values, you could also expand info properties at build time . Assuming you use Maven, you could rewrite the preceding example as follows: info.app.encoding[email protected]@ info.app.java.source[email protected]@ info.app.java.target[email protected]@

Another useful feature of the info endpoint is its ability to publish information about the state of your git source code repository when the project was built. If a GitProperties bean is available, the git.branch , git.commit.id , and git.commit.time properties are exposed.

	Tip
	A GitProperties bean is auto-configured if a git.properties file is available at the root of the classpath. See " Generate git information " for more details.

If you want to display the full git information (that is, the full content of git.properties ), use the management.info.git.mode property, as follows:

management.info.git.mode=full

If a BuildProperties bean is available, the info endpoint can also publish information about your build. This happens if a META-INF/build-info.properties file is available in the classpath.

	Tip
	The Maven and Gradle plugins can both generate that file. See " Generate build information " for more details.

To provide custom application information, you can register Spring beans that implement the InfoContributor interface.

The following example contributes an example entry with a single value:

import java.util.Collections;
import org.springframework.boot.actuate.info.Info;
import org.springframework.boot.actuate.info.InfoContributor;
import org.springframework.stereotype.Component;
@Component
public class ExampleInfoContributor implements InfoContributor {
	@Override
	public void contribute(Info.Builder builder) {
		builder.withDetail("example",
				Collections.singletonMap("key", "value"));
}

If you reach the info endpoint, you should see a response that contains the following