rfc7807

type DTO struct {
	// Type is a URI reference that identifies the problem type.
	// Ideally, the URI should resolve to human-readable information describing the type, but that’s not necessary.
	// The problem type provides more specific information than the HTTP status code itself.
	//
	// Type URI reference [RFC3986] identifies the problem type.
	// This specification encourages that, when dereferenced,
	// it provides human-readable documentation for the problem type (e.g., using HTML [W3C.REC-html5-20141028]).
	// When this member is absent, its value is assumed to be "about:blank".
	//
	// Consumers MUST use the "type" string as the primary identifier for
	// the problem type; the "title" string is advisory and included only
	// for users who are not aware of the semantics of the URI and do not
	// have the ability to discover them (e.g., offline log analysis).
	// Consumers SHOULD NOT automatically dereference the type URI.
	//
	// Example: "/errors/incorrect-user-pass"
	Type Type
	// Title is a human-readable description of the problem type,
	// meaning that it should always be the same for the same type.
	//
	// Example: "Incorrect username or password."
	Title string
	// Status The status reflectkit the HTTP status code and is a convenient way to make problem details self-contained.
	// That way, error replies can interpret outside the context of the HTTP interaction.
	// Status is an optional field.
	//
	// Example: 401
	Status int
	// Detail is a human-readable description of the problem instance,
	// explaining why the problem occurred in this specific case.
	//
	// Example: "Authentication failed due to incorrect username or password."
	Detail string
	// Instance is a URI that identifies the specific occurrence of the error
	// Instance is optional
	//
	// Example: "/login/log/abc123"
	Instance string
	// Extensions is a user-defined optional generic type that holds additional details in your error reply.
	// For example, suppose your company already has its error reply convention.
	// In that case, you can use the extension as a backward compatibility layer
	// to roll out the Handler standard in your project
	// without breaking any API contract between your server and its clients.
	//
	// Example: {...,"error":{"code":"foo-bar-baz","message":"foo bar baz"}}
	Extensions any
}

type DTOExt[Extensions any] struct {
	Type     Type
	Title    string
	Status   int
	Detail   string
	Instance string
	// Extensions is a user-defined optional generic structure type that holds additional details in your error reply.
	// For example, suppose your company already has its error reply convention.
	// In that case, you can use the extension as a backward compatibility layer
	// to roll out the Handler standard in your project
	// without breaking any API contract between your server and its clients.
	//
	// Example: {...,"error":{"code":"foo-bar-baz","message":"foo bar baz"}}
	Extensions Extensions
}

type Handler struct {
	// Mapping supplies the mapping logic that map the error value to a DTO[Extensions].
	Mapping HandlerMappingFunc
	// BaseURL is the URI path prefix the error types should have.
	// If none given, default is "/".
	BaseURL string
}

type HandlerMappingFunc func(ctx context.Context, err error, dto *DTO)

type Type struct {
	ID      string
	BaseURL string
}