Rest APIs in Go - using net/http vs. a library like Gorilla

Question

I see that Go itself has a package net/http, which is adequate at providing everything you need to get your own REST APIs up and running. However, there are a variety of frameworks; the most popular maybe say gorilla.

Considering that one of the main things I need to do going forward is to build REST APIs that will access some back-end storage (databases, caches, etc.) to perform CRUD operation, is it good to go with Go's standard library itself, or should I consider using some frameworks?

Normally, people write a new library or framework which solves the problem present in the existing library. But a lot of the frameworks also tend to make things worse when actual demands are simple.

So I have few questions:

1. Is the basic library in go lang good enough to support basic to moderate functionality for REST?

2. If I do end up using the inbuilt library and tomorrow have to change it to use some framework (like a gorilla), how difficult/costly would that be?

3. Are frameworks really addressing the problems or just making simple problems complex?

I would be extremely grateful for someone to share his thoughts here (who has been through making this choice himself) while I research more of my own.

Mcquade

What concrete use cases do you have in mind? – Precaution

For now , it is simple Get calls (my Api pulls data from some backend storage) , it may be Database (Sql or No Sql) or cache or both . Going forward it can be all CRUD operations as well . That being said , there are other things (neat error handling etc) . – Mcquade

Answer 1

The built-in net/http package is sufficient to build a complete REST API. However, some of the libraries can make building an API slightly easier, particularly if the REST API is complex. Changing from the built-in facilities to any decent framework is relatively straightforward - they generally accept handlers of the http.Handler type.

In the end, though, this is an extremely situational choice. The best thing you can do is examine each available solution, contrast and compare, and build a proof of concept with the top options if you possibly can. First-hand experience will guide you best.

Gerek

Thanks for response Adrian. Yes , I agree and am looking to do some Proof Of Concept to explore more things first hand . But POC can only do little (all I can make is simple rest API which I assume is easy and may not answer what I am looking here) . So I thought of asking it in a broader forum from developers who have spent some time building things with Go .Your reply sheds some light and gives me more clarity . – Mcquade

Answer 2

1. The net/http package is probably sufficient for most scenarios, but if you want to ease your development, you should use a third-party package, such as Gorilla. For example, net/http's ServeMux does a great job at routing incoming requests for fixed URL paths but for pretty paths which use variables, you will need to implement a custom multiplexer while using Gorilla, you are getting this for free.

   Another example is if you want to specify RESTful resources with proper HTTP methods, it is hard to work with the standard http.ServeMux, while with Gorilla's mux package, requests can be matched based on URL host, path, path prefix, schemes, header and query values, and HTTP methods.

2. One of the great benefits of Gorilla is that it is fully compatible with the net/http package and can be substituted in the future.

3. See 1.

I totally encourage you to use Gorilla's toolkit to develop REST services.

Sosthena

Thanks so much Shmulik , this was exactly kind of answer I was looking here – Mcquade

Keep in mind that gorilla isn't the only option - I've been using httprouter which is a bit more lightweight and I've had good success with it. It doesn't have as much functionality, it sits somewhere between the built in package and gorilla in terms of features. – Gerek

I like Gorilla. Keep in mind this project is now seeking a new maintainer. – Sanction

Gorilla project is about to be archived by the end of 2022. Some repositories under the Gorilla project are now archived, including mux. – Luminance