Live data from Hacker News

Ask HN: Anyone here switch to Go for building (REST) APIs?

news.ycombinator.com

41–50 of 51 posts

Re: Ask HN: Anyone here switch to Go for building (REST) APIs?

#41
post #34

Earlier quoted context omitted.

After reading the article you linked in another sibling comment's response, can you point to an example of what a true RESTful service looks like. I see how under that definition an API can't be RESTful, but what service then can be? And how do clients interact with it?

Basically a normal HTML website, that's true REST.

So if I made an API that would include in its responses other endpoints that can be hit, would that make it RESTful?

An example response could be

  {
    name: 'john',
    nickName: 'johnny',
    relatedEndpoints: ['/v2/friends', '/v2/jobs/', ...]
  }
Or one could include a link to an Open API spec for the API in the response of every request that details all endpoints available and their parameters/bodies.

  {
    name: 'john',
    nickName: 'johnny',
    apiSpec: '/v2/open-api-spec'
  }

Re: Ask HN: Anyone here switch to Go for building (REST) APIs?

#42

I switched from Python to Go for API development and never looked back. Performance is great, deployment is a breeze and the compiler and type system are good enough that my code normally works on the first try. I've also been building AWS Lambda backends and Go is great in that role as well. Workloads complete much more quickly than equivalent Python code and use a fraction of the memory.

i call BS on this. It's not python's fault and the change in performance due to language itself is minimal.

Re: Ask HN: Anyone here switch to Go for building (REST) APIs?

#43
Well if you ask people that specifically switched to Go, then all you are going to get is responses and anecdotes that meets your expectation.

However, if you ask people that switched away from Go, then you will see responses that also match that expectation.

So it really is down to your preference.

Re: Ask HN: Anyone here switch to Go for building (REST) APIs?

#44
post #34

Earlier quoted context omitted.

Basically a normal HTML website, that's true REST.

So if I made an API that would include in its responses other endpoints that can be hit, would that make it RESTful? An example response could be { name: 'john', nickName: 'johnny', relatedEndpoints: ['/v2/friends', '/v2/jobs/', ...] } Or one could include a link to an Open API spec for the API in the response of every request that details all endpoints available and their parameters/bodies. { name: 'john', nickName:…

No, that would not make it REST. I suspect you didn't read the article thoroughly?

If your application needs documentation, i.e. a spec or similar, also referred to by some as a "profile", in order for the client to use your resources beyond the initial root URI, then that is not REST!

An API, no matter how you twist or turn it, can never be REST. REST are truly only for manual human consumption, not machines. That is why it is so weird everyone is calling their APIs for REST.

Re: Ask HN: Anyone here switch to Go for building (REST) APIs?

#45

Yes, in 2017 and 3 companies later I've never looked back. Current application is an event-sourced system that includes a REST API, asynchronous event processing over SSE, and a scheduled job runner. It's been great. We don't use any frameworks, just the http package. It's blazing fast and highly reliable (low bug occurrence and easy refactors due to the safety provided by strong typing).

Which framework do you use to create your rest endpoints?

We use a mux router https://github.com/gorilla/mux#matching-routes

Re: Ask HN: Anyone here switch to Go for building (REST) APIs?

#46
post #31

Oh yeah, REST APIs are one of Go’s sweet spots. I have yet to find a better language for APIs and CLIs

Did you ever build HTTP based APIs in Java (or C#), what makes you prefer Go? I have been using Java for a long time but will soon be using Go because of a job change and I am trying to get a better sense of the trade-offs and advantages.

Yeah I've written HTTP APIs in Java, and they are fine for the most part, Go is just a little more lean, and simpler to work with

Re: Ask HN: Anyone here switch to Go for building (REST) APIs?

#47

I switched from Python to Go for API development and never looked back. Performance is great, deployment is a breeze and the compiler and type system are good enough that my code normally works on the first try. I've also been building AWS Lambda backends and Go is great in that role as well. Workloads complete much more quickly than equivalent Python code and use a fraction of the memory.

i call BS on this. It's not python's fault and the change in performance due to language itself is minimal.

It's no BS, go is much more performant. There are a lot of benchmarks out there. In the context of Lambda, it probably helps that I'm just shipping a compiled Go binary rather than a Python environment + dependencies. Regardless, there are Lambda workloads that are trivial with Go that are pretty much impossible with Python because of run time limits etc.

Re: Ask HN: Anyone here switch to Go for building (REST) APIs?

#48
post #44

Earlier quoted context omitted.

So if I made an API that would include in its responses other endpoints that can be hit, would that make it RESTful? An example response could be { name: 'john', nickName: 'johnny', relatedEndpoints: ['/v2/friends', '/v2/jobs/', ...] } Or one could include a link to an Open API spec for the API in the response of every request that details all endpoints available and their parameters/bodies. { name: 'john', nickName:…

No, that would not make it REST. I suspect you didn't read the article thoroughly? If your application needs documentation, i.e. a spec or similar, also referred to by some as a "profile", in order for the client to use your resources beyond the initial root URI, then that is not REST! An API, no matter how you twist or turn it, can never be REST. REST are truly only for manual human consumption, not machines. That i…

I read the article fully.

If an API response included all the possible actions and information that one takes as a follow up to a previous call, how is that any different from providing the equivalent forms and links to additional information on a web page rendered by a browser?

It certainly seems possible to pigeonhole an API into a RESTful architecture but I understand why based on the article, APIs aren't often considered RESTful.

But it seems they can be. I see this as a proof by contradiction.

I, today, can navigate directly to posts by a friend of mine on a social media site. Auto logged in, not having to enter any form data etc. That's my starting point both in a browser and via API.

I'd see their post. Alongside that post I'd see actions I can take: clicking on other friends' profiles, liking the post, commenting on the post, removing the friend etc.

Encoding all that in an API might look like this:

  {
    name: 'john',
    userId: '12'
    nickName: 'johnny',
    posts: [
      { content: 'My funny comment', likes: 3, likedByUserIds: ['13', '14', '15' ], postId: 333 },
      { ... }
    ]
    relatedEndpoints: [
      '/users/12/friends/', : {}
      '/users/13', : {}
      '/users/14', : {}
      '/users/15', : {}
      '/like/333, : {}
      '/unlike/333', : {}
      '/remove-friend/12', : {}
      '/comment/333/' : { commentText: '' }
      ...
    ]
  }
In this way, the response to my request includes all the possible actions I can then take and what data I need to provide to take it (in the example of the comment route).

* No consulting of external documentation is needed, all the information is right there. *

I can explore another user's profile (people with user ids of 13, 14, and 15), I can like and unlike this post with the `/like/` and `/unlike` routes, I can remove this person from my friends list etc.

Including such information makes this response no different than what I can do via browsing the page - all my interactions with the API are directly driven by their responses - not by consuming outside documentation.

If all possible actions and their routes were included on route supported by my API, why would this not be RESTful?

At the end of the day - this to me is a distinction without a difference. Whether this documentation is defined as part of the response or stored in an OpenAPI spec, the end result is the same - I can easily wire things up together to accomplish my goals.

This is where SDKs become more useful.

SDKs are fully documented, require no external information for them to be used, contain everything possible that can be done as methods etc.

If I get a `User` class back from an SDK - I can then invoke all the methods on that user like - getFriends, getPostById, etc etc.

If I call a `getFriendById(12)` method I'd expect a `Friend` instance rather than a more generic `User` instance which should have a `removeFriend` method but no `addFriend` method. That appears equally as RESTful as a website with actions that can be taken.

Re: Ask HN: Anyone here switch to Go for building (REST) APIs?

#49

Yes, go is still my go to technology for API work. I usually go about it like this: write an OpenAPI spec, generate clients and servers, implement individual operations. I like how lightweight a go implementation is and how easy, no-bs it is to setup a new module. I like go for apis.

This is the way I would like to go. Which generators do you use to transform the OpenAPI spec?

This one: https://github.com/deepmap/oapi-codegen, for chi.

Re: Ask HN: Anyone here switch to Go for building (REST) APIs?

#50
post #44

Earlier quoted context omitted.

No, that would not make it REST. I suspect you didn't read the article thoroughly? If your application needs documentation, i.e. a spec or similar, also referred to by some as a "profile", in order for the client to use your resources beyond the initial root URI, then that is not REST! An API, no matter how you twist or turn it, can never be REST. REST are truly only for manual human consumption, not machines. That i…

I read the article fully. If an API response included all the possible actions and information that one takes as a follow up to a previous call, how is that any different from providing the equivalent forms and links to additional information on a web page rendered by a browser? It certainly seems possible to pigeonhole an API into a RESTful architecture but I understand why based on the article, APIs aren't often co…

You're missing the point. If you provide an API like in the example you give, put it out on the net at some domain, then in order for it to be REST, I MYST be able to access that domain, without any prior knowledge whatsoever, and make a request.

When I do that in the case you provide, I would not know anything about how to use those resources. Without any prior knowledge, I don't know what "users" are, or what a "like" is or an "unlike". In order for me to use this resource, I need documentation. Even if you provide the documentation in the response to the request, and I have to read that first, then it is NOT REST.

By the very nature of an API, it can never be REST.

Post reply on HN