I have some constructive criticism for the author, please take this in the manner that it is intended :)
1) Nothing I see here is restful at all. Please consider changing your documentation to specifically mention consuming JSON Web APIs rather than REST, because its simply misleading.
2) Personally I LOATH chained function/method calls. As per your example:
api.Res("users", resp).Id(1).Get()
What happens if the argument passed to api.Res is not "users"? Or "users" is incorrect? Or if Id 1 doesnt exist? Or you cant use the HTTP method Get on the selected resource? Or if I want to use a HTTP method you haven't got a function for?
I assume the code panics because you are using method chaining your methods must return a single type you can't use the neat feature of Go of returning multiple types, specifically for errors.
3) By not being restful you have now made any code I write that consumes an API brittle to the changes of the API supplier i.e. the JSON response may change structure and break my code (this is less a criticism of your package and more about JSON Web APIs that refuse to learn from the lessons of REST).
4) How in the hell is this safe in any sense of the word, especially in an example of the use of the library:
if one of my developers wrote a line of code like that I would be having serious words with them regarding error checking. Encouraging this kind of foolhardy coding is irresponsible in my opinion, but that is just my opinion as I see an awful lot of this style of coding.
Sorry to be a debbie downer, but I think as a community of developers we should be promoting the best practices of our industry not constantly trying to explore shortcuts. For example, nothing I have seen in this package even acknowledges the existence of the network in the process. How does the developer using your package deal with network timeouts? 404s? 302s? 500s even?
Again, I hate seeing HN devolve into a bitching session just like the next person, so apologies to everyone, but this pushed a few of my personal insta-rage buttons.
>What happens if the argument passed to api.Res is not "users"? Or "users" is incorrect? Or if Id 1 doesnt exist? Or you cant use the HTTP method Get on the selected resource? Or if I want to use a HTTP method you haven't got a function for?
It is places like this where i would love to use railway oriented programming[1] or monads.
I love chaining function calls but can't do them without worrying about errors as you said, Someday i'll sit and try to implement Monads in Go
It's interesting to see how project like this gained attention for the HN crowds because it's written in Go while in platform like Java, client-side REST library like JAX-RS is a done-deal-dont-have-to-talk-about-it-lets-get-things-done.
There isn't much in Go that is dynamic. This looks to me to be some convenience around commonly consumed patterns applied to normal static struct definitions in Go.
Go does have reflection, but it's inspection mostly to take formatted data (JSON, etc.) and fill in statically defined structs with some hinting.
I don't think this is trying to be "passed off" as "dynamic."
Edit: I see "dynamic" is in the repo title. I concede the point - dynamic ain't the right word here, I would think.
1) Nothing I see here is restful at all. Please consider changing your documentation to specifically mention consuming JSON Web APIs rather than REST, because its simply misleading.
2) Personally I LOATH chained function/method calls. As per your example:
api.Res("users", resp).Id(1).Get()
What happens if the argument passed to api.Res is not "users"? Or "users" is incorrect? Or if Id 1 doesnt exist? Or you cant use the HTTP method Get on the selected resource? Or if I want to use a HTTP method you haven't got a function for?
I assume the code panics because you are using method chaining your methods must return a single type you can't use the neat feature of Go of returning multiple types, specifically for errors.
3) By not being restful you have now made any code I write that consumes an API brittle to the changes of the API supplier i.e. the JSON response may change structure and break my code (this is less a criticism of your package and more about JSON Web APIs that refuse to learn from the lessons of REST).
4) How in the hell is this safe in any sense of the word, especially in an example of the use of the library:
resource := api.Res("users").Id(123).Res("items", resp).Get(querystring)
if one of my developers wrote a line of code like that I would be having serious words with them regarding error checking. Encouraging this kind of foolhardy coding is irresponsible in my opinion, but that is just my opinion as I see an awful lot of this style of coding.
Sorry to be a debbie downer, but I think as a community of developers we should be promoting the best practices of our industry not constantly trying to explore shortcuts. For example, nothing I have seen in this package even acknowledges the existence of the network in the process. How does the developer using your package deal with network timeouts? 404s? 302s? 500s even?
Again, I hate seeing HN devolve into a bitching session just like the next person, so apologies to everyone, but this pushed a few of my personal insta-rage buttons.