REST API with Go — Gin or Echo Framework Choice and Best Practices That Work

You have a Go service to expose, but choosing between Gin and Echo is blocking you. Or you already picked one and routes become messy, validation is manual, middleware piles up without control. We've been there. On projects with dozens of endpoints, authentication, rate limiting, and structured logging, we had to decide and then optimize. In this guide we cover how to choose the framework, how to set a solid structure, and which best practices to apply right away — with real code.

Why Do Gin and Echo Dominate REST APIs in Go?

Both are minimalistic frameworks that don't sacrifice performance. Gin is built on httprouter, Echo on a proprietary router. The difference? Gin is more widespread, has more pre-built middleware, and a slightly lower learning curve. Echo is more explicit, with an API many find cleaner and integrated error handling Gin lacks. We use both depending on the project. The choice depends on how much control you need over the request lifecycle.

Best practice: don't choose based on hype. Download both, run the sample benchmark, and see which syntax feels more natural. For a simple API, Echo gives fewer surprises. For a complex API with lots of custom middleware, Gin gives more freedom.

What to Do Now

Install both and create a hello world endpoint in 5 minutes. Then compare error handling: Echo has c.JSON(http.StatusBadRequest, map[string]string{"error": err.Error()}) built-in, Gin requires c.AbortWithStatusJSON. Pick the one that feels cleaner.

How to Structure a Go REST API Project So You Don't Lose Your Mind?

The most common issue we see in teams asking for consulting: everything in a single main.go with 2000 lines. Unmaintainable. We imported from our Laravel and Livewire work a layered pattern: handler, service, repository. It's not mandatory, but for APIs with more than 10 endpoints it's a lifesaver.

Recommended structure:

api-project/
├── cmd/
│   └── server/
│       └── main.go
├── internal/
│   ├── handler/
│   │   └── user.go
│   ├── service/
│   │   └── user.go
│   ├── repository/
│   │   └── user.go
│   ├── middleware/
│   │   └── auth.go
│   └── model/
│       └── user.go
├── pkg/
│   └── config/
│       └── config.go
└── go.mod

Each layer has a single responsibility. Handler: request parsing and HTTP response. Service: business logic. Repository: data access (DB, external API). Middleware: logging, authentication, CORS. We use this pattern in all Go projects for real clients: it lets you test each layer separately.

Example with Gin: handler + service

// internal/handler/user.go
package handler

import (
	"net/http"
	"github.com/gin-gonic/gin"
	"api-project/internal/service"
)

type UserHandler struct {
	svc *service.UserService
}

func NewUserHandler(svc *service.UserService) *UserHandler {
	return &UserHandler{svc: svc}
}

func (h *UserHandler) GetUser(c *gin.Context) {
	id := c.Param("id")
	user, err := h.svc.GetUser(id)
	if err != nil {
		c.JSON(http.StatusNotFound, gin.H{"error": err.Error()})
		return
	}
	c.JSON(http.StatusOK, user)
}

Middleware, Validation, and Authentication — Which Best Practices to Adopt?

An API without middleware is an open door. We often see projects from other devs without rate limiting, without structured logging, with validation only on the frontend. Wrong. Every request must pass through middleware that logs method, path, duration, and status. Then authentication (JWT or API key). Then input validation.

Logging middleware with Echo

// internal/middleware/logger.go
package middleware

import (
	"log"
	"time"
	"github.com/labstack/echo/v4"
)

func RequestLogger() echo.MiddlewareFunc {
	return func(next echo.HandlerFunc) echo.HandlerFunc {
		return func(c echo.Context) error {
			start := time.Now()
			err := next(c)
			log.Printf("%s %s %d %s", c.Request().Method, c.Path(), c.Response().Status, time.Since(start))
			return err
		}
	}
}

Validation with Go structs

Use go-playground/validator tags. Both Gin and Echo support it natively with binding and validate.

type CreateUserRequest struct {
	Name  string `json:"name" binding:"required,min=3"`
	Email string `json:"email" binding:"required,email"`
	Age   int    `json:"age" binding:"gte=18"`
}

// In handler
var req CreateUserRequest
if err := c.ShouldBindJSON(&req); err != nil {
	c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
	return
}

Error Handling and Uniform Responses — How to Keep Consistency?

Nothing worse than an API that sometimes responds with {"error":"not found"}, sometimes with {"message":"404"}. We define a standard response structure: {"success":bool, "data":interface{}, "error":string}. And a middleware that catches unhandled errors and uniformizes them. With Echo this is built-in with HTTPErrorHandler. With Gin you need a global middleware.

Example with Gin: standard response

// pkg/response/response.go
package response

import (
	"net/http"
	"github.com/gin-gonic/gin"
)

type APIResponse struct {
	Success bool        `json:"success"`
	Data    interface{} `json:"data,omitempty"`
	Error   string      `json:"error,omitempty"`
}

func Success(c *gin.Context, data interface{}) {
	c.JSON(http.StatusOK, APIResponse{Success: true, Data: data})
}

func Error(c *gin.Context, status int, message string) {
	c.JSON(status, APIResponse{Success: false, Error: message})
}

What to Do Now

1. Download Gin and Echo and create a test endpoint with both. Choose the one that makes you write less code for your case.
2. Structure the project with handler/service/repository. Even for a small API, separate responsibilities.
3. Add middleware for logging, authentication, and rate limiting before any business logic.
4. Implement uniform responses with a shared response package.
5. Deep dive into the main pillar: Go for Backend — REST APIs and Microservices.

Official documentation: Gin Docs and Echo Docs.