He estado aprendiendo a codificar y recientemente terminé un proyecto de servidor-cliente en javascript. En ese servidor (Node.js) me escribí una función de "respondedor" que llamé docenas de veces a lo largo del programa:

 function sendResponse(req, res, err, response, redirect) { if (err) { res.status(err.status) return res.json(err.message || err.error) } if (response) { res.status(response.status) return res.json(response.response || response.message) } if (redirect) { return res.redirect(redirect) } res.status(500) return res.json({message: err.err || "Unknown server error", user: req.userObj.email || null}) }

Ahora estoy tratando de escribir un backend de servicio de API similar en Go. Si bien, por supuesto, puede pasar nil a las funciones, lo que no puedo entender es cómo permitir que cualquiera de esos parámetros sea "dinámico". ¿Quizás ese es el punto de un lenguaje tipificado estáticamente? En javascript, el parámetro de response podría ser un objeto con claves y valores de cadena, o podría tener objetos anidados con datos adicionales para enviar al cliente. En Go, podría tomar un mapa como parámetro, pero tendría que definirlo de antemano como un mapa cadena:cadena. Si quisiera anidar un mapa, también tendría que definir las asignaciones del mapa anidado.

Esto es lo más cerca que he estado en Go:

 func responder(w http.ResponseWriter, m map[string]string, s int) { w.WriteHeader(s) w.Header().Set("Content-Type", "application/json; charset=utf-8") if m != nil { r := createJson(m) w.Write(r) return } w.Write([]byte("Good job")) return } func createJson(m map[string]string) ([]byte) { j, err := json.Marshal(m) if err != nil { fmt.Println(err) return nil } return j }

Pero empiezo a tener la sensación de que solo estoy pensando en cómo hacer las cosas incorrectamente en lenguajes escritos estáticamente.

Editar: ¿Es este un trabajo para punteros? ¿Puedo usar un puntero a un mapa que puede o no contener mapas anidados?