Kissaki
should http.ResponseWriter be passed?
Instead of http.ResponseWriter being passed to the resources rest-fns the rest.go library should provide either provide a more general writer, an fmt.Fprinf-style function(s).
Yes, http.ResponseWriter should be passed.
rest.go does two things: it routes HTTP requests to a defined method, and provides a set of helper functions for common HTTP responses.
fmt.Fprintf already works with http.ResponseWriter (just pass it as the first argument). As http.ResponseWriter is an io.Writer, it is already a general writer.
I was thinking about putting a fmt.Fprinf wrapper function, so you don’t have to import and use the fmt function each time.
Same kind of dependency with the http package.
In general, I was thinking if a more abstract way of handling REST would be feasible. If you don’t want to edit http-response header etc, but just want to return a string/data (which will be put into the body), a simple string-pass or the like would be enough and a simpler API. Completely replacing the API is not what we want ofc, as one may want to have control over the response body. But IMO, most of the time, a simpler API would be enough.
For just a string response? Are you looking for something like the BadRequest method (but that returns a HTTP 200)? If it is just a simple string, then I can see this working.
Otherwise fmt.Fprintf is simpliest as it is an interface that most programmers should already know.
Also, using http.ResponseWriter allows for other (non-string) uses such as piping file data (images, etc) through the response using something like io.Copy.