

Show HN: Easily consume REST APIs with Go - bndr
https://github.com/bndr/gopencils

======
jalfresi
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:

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.

~~~
aksx
>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?

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

[1][http://fsharpforfunandprofit.com/posts/recipe-
part2/](http://fsharpforfunandprofit.com/posts/recipe-part2/)

------
edwinnathaniel
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.

------
mriehl
Looks simple enough, but I simply cannot push myself to using Go with json
because the approach feels so static and unnatural.

Also note that this library has no tests, which would be a showstopper for me.

------
TylerE
Is creating a new named type, creating a instance, and passing a pointer
really what passes for "dynamic" in the Go world?

~~~
themartorana
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.

