DEV Community: Solon Framework

Building a REST API with Solon 4.0: A Step-by-Step Guide

Solon Framework — Fri, 26 Jun 2026 16:18:50 +0000

Why Solon for REST APIs?

What drew me to Solon in the first place was how little code it takes to get something running. There's no heavy annotation processing, no XML configuration files to maintain, and the startup time is genuinely fast — we're talking sub-second for most small to mid-sized applications.

But more importantly, the API design feels intuitive if you've worked with modern Java frameworks. @Controller, @Mapping, @Inject — nothing exotic. You'll feel at home within minutes.

Prerequisites

Java 17+ installed on your machine
Maven 3.6+ (or use the Maven wrapper)
Your favorite IDE (I use IntelliJ, but VS Code works fine too)

Project Setup

Let's start by creating a Maven project. I prefer doing this manually so I understand every piece that goes in.

Create the following directory structure:

user-api/
├── pom.xml
└── src/
    └── main/
        ├── java/
        │   └── com/
        │       └── demo/
        │           ├── App.java
        │           ├── controller/
        │           │   └── UserController.java
        │           ├── model/
        │           │   └── User.java
        │           └── mapper/
        │               └── UserMapper.java
        └── resources/
            ├── app.yml
            └── mybatis/
                └── UserMapper.xml

pom.xml

Here's the Maven setup. I'm using solon-web as the core dependency — it bundles everything you need for REST API development:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
         http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.demo</groupId>
    <artifactId>user-api</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <java.version>17</java.version>
        <solon.version>4.0.2</solon.version>
    </properties>

    <dependencies>
        <!-- Solon Web (MVC + HTTP server) -->
        <dependency>
            <groupId>org.noear</groupId>
            <artifactId>solon-web</artifactId>
            <version>${solon.version}</version>
        </dependency>

        <!-- MyBatis-Solon integration -->
        <dependency>
            <groupId>org.noear</groupId>
            <artifactId>solon-data-mybatis-plus-extension-solon-plugin</artifactId>
            <version>${solon.version}</version>
        </dependency>

        <!-- H2 database (for development) -->
        <dependency>
            <groupId>com.h2database</groupId>
            <artifactId>h2</artifactId>
            <version>2.2.224</version>
            <scope>runtime</scope>
        </dependency>

        <!-- Lombok (optional, but saves boilerplate) -->
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.18.30</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.11.0</version>
                <configuration>
                    <source>17</source>
                    <target>17</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

Note: I'm using solon-data-mybatis-plus-extension-solon-plugin here because it bundles MyBatis with useful extensions. If you prefer plain MyBatis, solon-data-mybatis-solon-plugin works too.

The Main Class

Every Solon application needs an entry point. It's refreshingly minimal:

package com.demo;

import org.noear.solon.Solon;

public class App {
    public static void main(String[] args) {
        Solon.start(App.class, args);
    }
}

That's it. Solon.start() scans the package, picks up your controllers and configurations, and starts the embedded server (default port is 8080). No @SpringBootApplication, no @EnableAutoConfiguration.

Configuration File

Solon uses app.yml by default (YAML is my preference, but it supports .properties too):

server:
  port: 8080

solon.data:
  schema: classpath:db/schema.sql  # Auto-run on startup

datasource:
  user:
    class: org.h2.Driver
    url: jdbc:h2:mem:userdb
    username: sa
    password:

mybatis:
  user:
    mapperPackage: com.demo.mapper

Let me explain this quickly:

solon.data.schema points to a SQL file that creates our tables on startup
datasource.user defines an H2 in-memory database named userdb
mybatis.user.mapperPackage tells MyBatis where to find mapper interfaces

Create a SQL file at src/main/resources/db/schema.sql:

CREATE TABLE IF NOT EXISTS users (
    id      BIGINT AUTO_INCREMENT PRIMARY KEY,
    name    VARCHAR(50) NOT NULL,
    email   VARCHAR(100) NOT NULL,
    age     INT DEFAULT 0,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Creating the Domain Model

I like keeping things simple. A User model with a few fields:

package com.demo.model;

import lombok.Data;

@Data
public class User {
    private Long id;
    private String name;
    private String email;
    private Integer age;
}

Data Access Layer with MyBatis

The Mapper Interface

package com.demo.mapper;

import com.demo.model.User;
import org.apache.ibatis.annotations.Mapper;

import java.util.List;

@Mapper
public interface UserMapper {
    List<User> findAll();
    User findById(long id);
    void insert(User user);
    int update(User user);
    int deleteById(long id);
}

The XML Mapper

Place this at src/main/resources/mybatis/UserMapper.xml:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.demo.mapper.UserMapper">

    <resultMap id="userMap" type="com.demo.model.User">
        <id column="id" property="id"/>
        <result column="name" property="name"/>
        <result column="email" property="email"/>
        <result column="age" property="age"/>
    </resultMap>

    <select id="findAll" resultMap="userMap">
        SELECT * FROM users ORDER BY id
    </select>

    <select id="findById" resultMap="userMap">
        SELECT * FROM users WHERE id = #{id}
    </select>

    <insert id="insert" useGeneratedKeys="true" keyProperty="id">
        INSERT INTO users (name, email, age)
        VALUES (#{name}, #{email}, #{age})
    </insert>

    <update id="update">
        UPDATE users
        SET name = #{name},
            email = #{email},
            age = #{age}
        WHERE id = #{id}
    </update>

    <delete id="deleteById">
        DELETE FROM users WHERE id = #{id}
    </delete>

</mapper>

Building the REST Controller

Now for the main event — the controller. This is where Solon's simplicity really shines:

package com.demo.controller;

import com.demo.mapper.UserMapper;
import com.demo.model.User;
import org.noear.solon.annotation.*;

import java.util.HashMap;
import java.util.List;
import java.util.Map;

@Controller
@RequestMapping("/api/users")
public class UserController {

    @Inject
    private UserMapper userMapper;

    @Get
    public List<User> getAll() {
        return userMapper.findAll();
    }

    @Get
    @Mapping("/{id}")
    public User getById(@Path long id) {
        return userMapper.findById(id);
    }

    @Post
    public Map<String, Object> create(@Body User user) {
        userMapper.insert(user);
        Map<String, Object> result = new HashMap<>();
        result.put("id", user.getId());
        result.put("message", "User created successfully");
        return result;
    }

    @Put
    @Mapping("/{id}")
    public Map<String, String> update(@Path long id, @Body User user) {
        user.setId(id);
        int rows = userMapper.update(user);
        Map<String, String> result = new HashMap<>();
        if (rows > 0) {
            result.put("message", "User updated successfully");
        } else {
            result.put("message", "User not found");
        }
        return result;
    }

    @Delete
    @Mapping("/{id}")
    public Map<String, String> delete(@Path long id) {
        int rows = userMapper.deleteById(id);
        Map<String, String> result = new HashMap<>();
        if (rows > 0) {
            result.put("message", "User deleted successfully");
        } else {
            result.put("message", "User not found");
        }
        return result;
    }
}

A few things I really like here:

@Inject instead of @Autowired — less magic, more explicit
@Get, @Post, @Put, @Delete — HTTP-method-specific annotations that keep things readable
@Body for automatic request body deserialization (works with JSON by default)
@Path for path variables — no @PathVariable("id") ceremony needed

Solon uses solon.serialization.json under the hood, which auto-detects Jackson if it's on the classpath. Since solon-web brings Jackson in transitively, JSON works out of the box.

Running and Testing

Start the Application

mvn clean compile exec:java -Dexec.mainClass="com.demo.App"

Or simply run App.main() from your IDE. You should see something like:

2026-06-27 00:15:32.145 INFO  [main] - Solon v4.0.2 started in 0.86s
2026-06-27 00:15:32.150 INFO  [main] - HttpServer on port 8080

0.86 seconds. That's what surprised me the most the first time I ran it — the framework starts in under a second even with MyBatis and H2 wired up.

Test the API

Let's exercise the endpoints:

# Create a user
curl -X POST http://localhost:8080/api/users \
  -H "Content-Type: application/json" \
  -d '{"name":"Alice","email":"alice@example.com","age":28}'

# Response: {"id":1,"message":"User created successfully"}

# Create another user
curl -X POST http://localhost:8080/api/users \
  -H "Content-Type: application/json" \
  -d '{"name":"Bob","email":"bob@example.com","age":35}'

# Get all users
curl http://localhost:8080/api/users

# Response:
# [{"id":1,"name":"Alice","email":"alice@example.com","age":28,"createdAt":...},
#  {"id":2,"name":"Bob","email":"bob@example.com","age":35,"createdAt":...}]

# Get a single user
curl http://localhost:8080/api/users/1

# Update a user
curl -X PUT http://localhost:8080/api/users/1 \
  -H "Content-Type: application/json" \
  -d '{"name":"Alice Johnson","email":"alice.j@example.com","age":29}'

# Delete a user
curl -X DELETE http://localhost:8080/api/users/2

Everything works as expected. JSON serialization is clean — camelCase Java fields map to camelCase JSON keys by default, and the created_at column is automatically handled.

What I Found Interesting

A few takeaways from building this:

Startup time is addictive. Once you experience sub-second startup, waiting 5–10 seconds for other frameworks to boot starts to feel painful.
The API surface is small but sufficient. Solon doesn't try to do everything — it does the core things well and gets out of your way. The entire controller above uses only 6 annotations.
Minimal surprises. Everything worked on the first run (once I got the config right). No mysterious auto-configuration failures, no circular dependency issues.

Summary

We built a complete REST API with Solon 4.0 in under 100 lines of Java code (excluding config and XML). The framework's philosophy is clear: be fast, stay simple, and trust the developer.

I've put the full project on GitHub if you want to clone it and play around. In my next post, I'll explore adding validation, exception handling, and maybe a dash of AOP.

Have you tried Solon for building APIs? I'd love to hear about your experience. Drop a comment or reach out — I'm still learning the framework myself, and there's always something new to discover.

Getting Started with Solon 4.0: A Modern Java Framework That Puts Performance First

Solon Framework — Fri, 26 Jun 2026 11:25:21 +0000

Getting Started with Solon 4.0: A Modern Java Framework That Puts Performance First

I've been working with Java frameworks for a while — started with Spring Boot back in the 1.x days, watched it grow into the ecosystem it is today. But lately, I've been exploring alternatives, and one that genuinely surprised me is Solon.

Solon isn't new (it's been around since 2018), but version 4.0, released just a couple of weeks ago, marks a significant milestone. I wanted to share a practical walkthrough — what Solon is, why it's worth your attention, and how to get started in under 5 minutes.

What Is Solon?

Solon is a next-generation Java application development framework. It's built from scratch (not a wrapper around existing specs), and follows four core principles:

克制 (Restraint) — A tiny kernel of ~0.3MB. No bloat, no compromises.
高效 (Efficiency) — 300%–700% higher concurrency, 50% less memory, 10x faster startup, 90% smaller packages.
开放 (Openness) — Own specification standard, compatible with Java 8 through Java 26, GraalVM Native Image support.
生态 (Ecosystem) — 300+ plugins covering Web, Cloud, AI, Data, Security, Scheduling, and more.

It's Apache 2.0 licensed, developed by the Noear team (Hangzhou, China), and backed by 90+ enterprise users including Meituan, Kuaishou (快手), Gree, China Life Insurance, and CETC.

The Numbers That Got My Attention

Let's be honest — performance claims are cheap without benchmarks. Here's what I verified:

TechEmpower Benchmarks

Solon consistently ranks competitively in the TechEmpower Web Framework Benchmarks. But what's more concrete is the head-to-head comparison from the official docs:

Server	Size	QPS (Requests/sec)
Solon (SmartHTTP - AIO)	0.7MB	~166,000
Solon (JDK HTTP - BIO)	0.2MB	~64,000
Solon (Jetty - NIO)	2.2MB	~123,000
Solon (Undertow - NIO)	4.5MB	~120,000
Spring Boot (Tomcat)	16.1MB	~32,000
Spring Boot (Jetty)	16MB	~37,000
Spring Boot (Undertow)	16.8MB	~44,000

Source: Solon official feature page

That's not a small difference — we're talking 3-5x the throughput with 1/20th the package size. In containerized and serverless environments, this translates directly to cost savings.

Community Growth

Metric	Value
GitHub + Gitee Stars	6,800+
Contributors	124
Commits	17,000+
Maven Releases	984
Downloads (last 6 months)	12,000,000+
Enterprise Users	90+

These aren't vanity metrics — 12 million downloads in half a year suggests real production usage.

5-Minute Quickstart

Enough with the numbers. Let's write some code.

Step 1: Create a Project

The fastest way is to download a Maven template from the Solon Initializr, or just use this minimal pom.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
         http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example</groupId>
    <artifactId>solon-demo</artifactId>
    <version>1.0.0</version>
    <packaging>jar</packaging>

    <parent>
        <groupId>org.noear</groupId>
        <artifactId>solon-parent</artifactId>
        <version>4.0.2</version>
    </parent>

    <dependencies>
        <dependency>
            <groupId>org.noear</groupId>
            <artifactId>solon-web</artifactId>
        </dependency>
    </dependencies>
</project>

Step 2: Write Your First Controller

package com.example.demo;

import org.noear.solon.annotation.*;

@Controller
public class DemoController {

    @Mapping("/hello")
    public String hello(@Param(defaultValue = "world") String name) {
        return String.format("Hello %s!", name);
    }
}

Step 3: Add the Main Class

package com.example.demo;

import org.noear.solon.Solon;

public class App {
    public static void main(String[] args) {
        Solon.start(App.class, args);
    }
}

That's it. No @SpringBootApplication, no @EnableAutoConfiguration, no XML config files.

Step 4: Run & Test

# Start
mvn exec:java

# Or build and run
mvn clean package -DskipTests
java -jar target/solon-demo.jar

# Test it
curl "http://localhost:8080/hello?name=Solon"
# → Hello Solon!

Startup time? On my MacBook, it's under 1 second for a basic web app. Not "warm-up" time — actual ready-to-serve time.

What Makes Solon Different?

1. No Servlet Container Dependency

Solon doesn't depend on Servlet API or Java EE. It has its own lightweight HTTP server abstraction. You can choose from multiple server implementations:

SmartHTTP (AIO, NIO-based, ~0.7MB) — best performance
JDK HTTP Server (~0.2MB) — minimal footprint
Jetty (~2.2MB) — Servlet API compatible
Undertow (~4.5MB) — Servlet API compatible

Each is a separate Maven dependency, so you only ship what you use.

2. Multi-Language Support

Solon works with Java, Kotlin, and Groovy — all first-class citizens, not afterthoughts:

@Controller
class App {
    @Get
    @Mapping("/hello")
    fun hello(@Param(defaultValue = "world") name: String): String {
        return "Hello $name!"
    }
}

3. 300+ Plugins — True Ecosystem Coverage

Solon's plugin ecosystem covers virtually every scenario you'd need in production:

Category	Plugins
Web	MVC, SSE, WebSocket, Reactive, RESTful
Data	MyBatis, MyBatis-Flex, JPA, jDBI, Hibernate, MongoDB, Redis
Cloud	Nacos, Consul, Eureka, Gateway, Config, Tracing
AI	LLM integration (OpenAI, Ollama, etc.), MCP protocol, Agent framework
Security	Sa-Token, OAuth2, JWT, RBAC
Flow	Workflow engine, rule engine, state machine
Scheduling	Cron jobs, distributed scheduling
Testing	JUnit 5 integration, mock support

4. Java 8 to 26 — One Framework, All Versions

This might sound trivial, but if you've ever tried to upgrade a Spring Boot 2.x project to Spring Boot 3.x (and the Jakarta migration nightmare), you'll appreciate this: Solon supports Java 8 through Java 26 with the same API. No breaking package renames, no forced migration.

What's New in Solon 4.0

The v4.0 release (June 10, 2026) brought several meaningful improvements:

AI Ecosystem Overhaul

Skill → Talent renaming: Framework-level capabilities are now "Talents" to avoid confusion with Agent skills. Cleaner semantics.
MCP Protocol v2025-11-25: Full support for the latest Model Context Protocol, including ServerTransportSecurityValidator for authentication.
Context Compression: The ContextCompressionInterceptor (renamed from SummarizationInterceptor) now compresses at onReasonStart instead of onObservation, preventing intermediate state loss in long agent conversations.

Plugin Normalization

Several popular third-party integrations moved from the Solon repository to their official maintainers:

mybatis-plus-solon-plugin → com.baomidou:mybatis-plus-solon-plugin
sa-token-solon-plugin → cn.dev33:sa-token-solon-plugin
liteflow-solon-plugin → com.yomahub:liteflow-solon-plugin
And more (forest, sms4j, beetlsql, dbvisitor...)

This is a healthy sign of ecosystem maturity — upstream projects are investing in Solon compatibility.

API Cleanup

v4.0 removed deprecated APIs accumulated over years. If you're upgrading from 3.10.x, the migration path is well-documented: upgrade to 3.10.7 first → fix deprecation warnings → jump to 4.0.

Should You Try Solon?

If you're happy with your current stack and productivity is great — keep going. But if you're:

Starting a greenfield project and want to minimize infrastructure cost
Running microservices where every MB of memory and ms of startup time matters
Deploying to serverless/container environments where cold starts are painful
Maintaining legacy Java 8/11 systems and want a modern framework without a forced JDK upgrade
Curious about alternatives to the Spring-dominated ecosystem

...then Solon is absolutely worth a weekend project to kick the tires.

The best part? It took me longer to write this article than to build my first Solon app. The learning curve is genuinely shallow if you're familiar with annotation-based Java frameworks.

Links

Resource	URL
Official Site	solon.noear.org
GitHub	github.com/opensolon/solon
Documentation	solon.noear.org/article/learn-start
Project Generator	solon.noear.org/start/
TechEmpower Benchmarks	techempower.com

This article uses Solon version 4.0.2, the latest stable release as of June 2026. All performance data is sourced from the official documentation and TechEmpower benchmarks.