APIJSON: JSON in the request decides what the database returns

A request payload that doubles as a query and a response shape

Most Java web frameworks separate three things: the query, the response shape, and the HTTP endpoint that connects them. APIJSON collapses them. The project describes itself as a real-time no-code ORM where the backend gets its APIs and documentation without writing code, and the frontend can customise the JSON it receives back.

The mechanism implied by the name is straightforward. You POST or GET a JSON document whose keys describe what to select, which conditions to apply, and how to shape the result. The library parses it, generates SQL, runs it and serialises the rows into the JSON structure the caller asked for. There is no entity class to write, no DTO, no mapper and no controller method per table.

That is a genuinely different design from an ORM in the JPA or Hibernate sense, where you map a class to a table and the framework derives queries from object state. Here the query is data, which is why the project calls it no-code. The risk follows from the same property: if the request can express arbitrary selection and conditions, then whatever validates and authorises that request is the entire security boundary of your API.

Version numbering that starts at eight and moves every few weeks

The release tags are the fastest way to gauge the project's pace, and they are unusual. The three most recent are 8.3.0 published on 2026-08-11, 8.2.0 on 2026-07-17 and 8.1.8 on 2026-05-16. A library that is on version eight has either had a long history or a versioning policy that counts features rather than following semantic versioning from the start.

What the releases contain is more informative than the numbers. 8.3.0 added an `UPSERT_TABLE_MAP` entry to `AbstractSQLConfig` for insert-or-increment behaviour, made the mixed CRUD method directives order-independent, and added support for KingbaseES running in MySQL, Oracle or SQL Server compatibility modes. 8.2.0 added StarRocks support and added links for LLM AI skills, MCP and A2A, including a `context7.json` file. 8.1.8 added an `@trim` keyword for stripping whitespace from string values, adjusted the capacity estimate for very large result sets, and replaced `printStackTrace()` with proper logging.

Several of those are visible fixes to behaviour a caller would notice: an upgrade that changes whether your directives run in the order you wrote them is not a drop-in release. The repository is not archived and the last push was on 2026-09-20, so the churn is current rather than historical. Read a release before upgrading rather than after.

Database breadth is the real feature list

The README leads with a wall of database badges, and reading them carefully is the best coverage assessment available. The relational targets name MySQL 5.7 and up, PostgreSQL 9.5 and up, SQL Server 2012 and up, Oracle 12c and up, DB2 7.1 and up, plus MariaDB 10.0, TiDB 2.1, openGauss 5.0, Dameng 7.6, Kingbase 8.6 and KingbaseES v9.

Then it widens well past relational databases. The badges include ClickHouse 21.1, Doris 2.1, StarRocks 4.1, QuestDB 8.2, Elasticsearch 7.17, OpenSearch via PostGIS-adjacent entries, Snowflake 7.0, Databricks 13.0, Presto, Trino, DuckDB 1.1, SQLite 3.46, SurrealDB 2.0, MongoDB, Cassandra 2.1, InfluxDB 2.6, TDengine 2.6, IoTDB 1.3, Milvus 2.2.0, DataBend 1.2, TimescaleDB 17.1 and Hive 3.1 with Hadoop 3.1. Redis 5.0 and Kafka 3.2 appear as multi data source targets rather than primary stores.

Not every badge means the same depth of support. Some point at a demo directory in a separate APIJSON-Demo repository, some at a fork maintained by an individual, and at least one is a link to a database project with a similarly named repository. The repository topics are a shorter version of the same list and lean analytical: clickhouse, elasticsearch, influxdb, milvus, snowflake, databricks, hive, hadoop, tdengine, tidb, sqlserver, oracle, postgresql. Verify your specific engine in the demo repository before committing.

Five README variants and a design document pair in the tree

The repository root explains a lot about how the project is organised, because documentation is treated as a first-class artefact rather than an afterthought. There is `README.md` and `README-Chinese.md`, `README-extend.md`, `Document.md` and `Document-Chinese.md`, plus a Chinese file named `详细的说明文档.md`, which translates roughly as detailed documentation. `Navigation.md` exists to tie the documents together, and `Roadmap.md` records intent.

Two files at the root are unusual for a code repository: `APIJSON初期构思及实现.docx` and the matching `.pages` file. Those are the original concept and implementation documents, in Word and Apple Pages formats, kept in the repository rather than moved to a wiki. Reading them would tell you what the authors were solving before the code existed.

Alongside the docs sit `CONTRIBUTING.md` and a separate `CONTRIBUTING_COMMIT.md` for commit conventions, a `LICENSE` file, and a `context7.json` at the root. The build itself is a plain Maven project: `pom.xml` with `src/` beneath it, no Gradle configuration and no wrapper scripts in the tree.

The bilingual documentation split matters for adoption. The English README is a badge wall and a navigation hub rather than a tutorial, which means the real explanation lives in the documentation site at apijson.cn and in the longer documents. If you are not comfortable reading Chinese documentation, budget more time than the repository layout suggests.

AI tooling bolted onto the docs in 8.2.0

The 8.2.0 release added an entry point for large language model tooling, and the README now links a DeepWiki page, a Context7 skills page and an MCP page. The `context7.json` file at the repository root is the machine readable counterpart.

This is worth naming plainly rather than treating as a technical feature. What it signals is a deliberate attempt to make the project's documentation consumable by coding agents, so a tool can look up APIJSON conventions without scraping the site. For a project whose whole value proposition is a request syntax, that syntax needs to be in machine readable form for the approach to survive being used through an assistant. The release notes also mention an A2A link, which points the same direction.

The README's own framing is that you can ask an AI about the project through those links. Whether that is a better way to learn the request syntax than the documentation site is the open question, since the request format is exactly the kind of detail where a hallucinated field name costs you an afternoon. The video links on Bilibili and the live test instance at apijson.cn/api exist for the same reason: you can check a syntax question against something running.

Where this differs from JSON:API and from a generated OpenAPI layer

Google's own questions for this project are about JSON:API and about why JSON shows up in APIs at all, which points at the real comparison. APIJSON is not an implementation of any API specification. It is a convention where the request is a query description and the response is negotiated by the caller. JSON:API is the opposite: a fixed, documented resource format with a strict relationship model, designed so that many client teams can predict responses without reading server code.

The other common alternative is generating a conventional REST layer from a schema and publishing OpenAPI documentation. That approach costs a schema definition and a generation step, and it gives you a stable contract, generated docs, and endpoints you can put behind a gateway with standard validation. APIJSON skips all of that and gets you a working endpoint immediately.

So the decision is not really technical. If the consumers are your own frontends in a monorepo, where the client developer can read the library, APIJSON's flexibility is an asset. If the consumers are third parties, or if you need to enforce a contract, the effort of writing controllers or generating a schema is the cost of doing business properly. Nothing in the repository documentation settles that choice for you, and the README's no-code framing is not an argument either way.

Editorial conclusion

APIJSON suits a Java team that wants read and write endpoints over existing tables without hand-writing controllers, and that is willing to let the request payload carry the query. It is the wrong choice for a public API with external developers, where a documented and stable schema matters more than a short path from table to endpoint, and the JSON:API specification exists for exactly that case. Check three things first: which of your databases are actually supported rather than merely listed as a topic, whether the authorisation model documented on apijson.cn fits a multi-tenant deployment, and whether your MySQL or PostgreSQL version clears the badge floor the README states. The test instance at apijson.cn/api is the fastest way to see the request syntax before you read the full documentation.

Frequently asked questions

Official sources

1. APIJSON/APIJSON on GitHub
2. Issues
3. Project website
4. README
5. Releases