Description

The healthcheck middleware now supports multiple response formats (JSON, XML, MessagePack, CBOR) in addition to the default plain text format. This allows applications to maintain consistent API contracts across all endpoints, including health checks.

Changes introduced

• New ResponseFormat configuration: Added ResponseFormat field to Config with 5 format options:

  • FormatText (default, backward compatible)
  • FormatJSON
  • FormatXML
  • FormatMsgPack
  • FormatCBOR

• Response structure: Introduced healthResponse struct that serializes consistently across all formats using proper struct tags (json, xml, msgpack, cbor) to ensure lowercase "status" key in all encodings:

  • Success: {"status":"OK"} (JSON example)
  • Failure: {"status":"Service Unavailable"}

• Documentation Update:

  • Added "Response Formats" section with usage examples
  • Documented encoder configuration requirements for MsgPack and CBOR with self-contained code snippets including all necessary imports (fiber/v3, middleware/healthcheck, encoder libraries)
  • Updated config documentation with new field and correct ResponseFormat type definition with iota
  • docs/middleware/healthcheck.md

• Comprehensive test coverage: Added test cases for all 5 formats validating:

  • Correct Content-Type headers
  • Success and failure response bodies
  • Status code correctness (200 OK / 503 Service Unavailable)
  • MsgPack and CBOR body decoding with field key casing and value assertions
  • Tests use exported LivenessEndpoint and ReadinessEndpoint constants for consistency with the rest of the test suite

• Changelog/What's New: Healthcheck middleware now supports configurable response formats (Text, JSON, XML, MsgPack, CBOR) while maintaining full backward compatibility.

• API Longevity: The ResponseFormat enum pattern provides extensibility for future formats without breaking changes. Default behavior (plain text) is unchanged, ensuring zero impact on existing deployments. Constant names follow Fiber's established naming conventions for brevity and clarity.

• Examples:

// JSON format
app.Get(healthcheck.LivenessEndpoint, healthcheck.New(healthcheck.Config{
    ResponseFormat: healthcheck.FormatJSON,
}))
// GET /livez → {"status":"OK"}

// XML with custom probe
app.Get(healthcheck.ReadinessEndpoint, healthcheck.New(healthcheck.Config{
    ResponseFormat: healthcheck.FormatXML,
    Probe: func(c fiber.Ctx) bool {
        return database.Ping() == nil
    },
}))
// GET /readyz → <healthResponse><status>OK</status></healthResponse>

// MsgPack (requires encoder configuration)
app := fiber.New(fiber.Config{
    MsgPackEncoder: msgpack.Marshal,
})
app.Get(healthcheck.LivenessEndpoint, healthcheck.New(healthcheck.Config{
    ResponseFormat: healthcheck.FormatMsgPack,
}))

Type of change

• New feature (non-breaking change which adds functionality)
• Enhancement (improvement to existing features and functionality)
• Documentation update (changes to documentation)

Checklist

• Conducted a self-review of the code and provided comments for complex or critical parts.
• Updated the documentation in the /docs/ directory for Fiber's documentation.
• Added or updated unit tests to validate the effectiveness of the changes or new features.
• Ensured that new and existing unit tests pass locally with the changes.
• Verified that any new dependencies are essential and have been agreed upon by the maintainers/community.
• Aimed for optimal performance with minimal allocations in the new code.