nethttp.RequestMapping not work for json input data

[keenranger]

I want to seperate concerns between usecases and transport it, so I tried nethttp.RequestMapping() as shown on README.md.
But I found it doesn't work for json body, and I started debug the package.

package rest has 6 const ParamIn

const (
	// ParamInPath indicates path parameters, such as `/users/{id}`.
	ParamInPath = ParamIn("path")

	// ParamInQuery indicates query parameters, such as `/users?page=10`.
	ParamInQuery = ParamIn("query")

	// ParamInBody indicates body value, such as `{"id": 10}`.
	ParamInBody = ParamIn("body")

	// ParamInFormData indicates body form parameters.
	ParamInFormData = ParamIn("formData")

	// ParamInCookie indicates cookie parameters, which are passed ParamIn the `Cookie` header,
	// such as `Cookie: debug=0; gdpr=2`.
	ParamInCookie = ParamIn("cookie")

	// ParamInHeader indicates header parameters, such as `X-Header: value`.
	ParamInHeader = ParamIn("header")
)

But in RequestMapping

// RequestMapping creates rest.RequestMapping from struct tags.
//
// This can be used to decouple mapping from usecase input with additional struct.
func RequestMapping(v interface{}) func(h *Handler) {
	return func(h *Handler) {
		m := make(rest.RequestMapping)

		for _, in := range []rest.ParamIn{
			rest.ParamInFormData,
			rest.ParamInQuery,
			rest.ParamInHeader,
			rest.ParamInPath,
			rest.ParamInCookie,
		} {
			mm := make(map[string]string)

			refl.WalkTaggedFields(reflect.ValueOf(v), func(v reflect.Value, sf reflect.StructField, tag string) {
				mm[sf.Name] = tag
			}, string(in))

			if len(mm) > 0 {
				m[in] = mm
			}
		}

		if len(m) > 0 {
			h.ReqMapping = m
		}
	}
}

only 5 of them are used without body for json input. I wonder is this intended.

[vearutop]

JSON body, as opposed to other parameters, can be a nested structure of arbitrary complexity. This makes custom field mapping more difficult, than flat map of other parameters.

From a technical perspective, json body is decoded with a standard encoding/json API that does not allow custom mapping interception. Other parameters are decoded with a custom library that allows custom mapping during decoding.

Also json field tag does not have such a direct transport belonging as say query, it is a transport-agnostic serialization tag and might be tolerated as a part of usecase/domain code.

These considerations led to a decision to support custom mapping only for non-json parameters.
I think it is worth updating the docs to make this behavior limitations more visible.

Potentially, mapping handling could be changed to support json fields, though I don't have a good idea on how useful that would be and what could be a strategy for a reliable implementation.

[keenranger]

To be usecase independant of all transport protocol(e.g. grpc) I thought dividing transport layer and service layer is useful. But I also understand it isn't easy mapping json body.
Thank you for answering and closing issue 👍