One system instead of four

Apifox is a tool for the whole life of an interface: writing its documentation, debugging it, mocking it before the backend exists and running automated tests against it afterwards. The design decision behind it is that all four activities read the same data. A project keeps one description of an interface, and everything else is derived from that description, which is the part that removes the familiar problem of two systems holding two versions of the same API.

The vendor's own summary names four areas — API documentation, API debugging, API mock and API automated testing — and the public SaaS edition is currently free of charge, without a limit on team members, features, projects or the number of interfaces.

Designing the documentation

Scenario tests, which run a sequence of calls as one flow, check that the data travelling between them stays correct. Assertions are written visually rather than as code, variables can be extracted from a response, and SQL can be run against a database in the middle of a flow. Pre-request and post-response scripts can be supplied for custom checks, and their syntax is fully compatible with Postman scripts, which keeps the learning cost low for a team arriving from that tool.

Scripts are not restricted to JavaScript. Code in javascript, java, python, php, js, BeanShell, go, shell, ruby and lua can be called, so a team does not have to rewrite an existing helper in another language.

Debugging

The debugging view carries what an interface tool is expected to have: environment variables, pre-request and post-response scripts, and Cookie and Session data shared across requests. On top of that it validates the structure of a response against the definition in the documentation, so a field that changed type or disappeared is reported instead of being noticed a week later.

Cases belong to an interface rather than to a session: one interface can hold several cases, each with its own parameters and expectations. Assertions, variable extraction and SQL operations are configured visually here as well, which keeps the same working style across design, debugging and testing.

Mocking and automated testing

Mocking needs no configuration: the tool derives plausible data from the API documentation itself. A built-in Mock.js rule engine allows the rules to be set while a data structure is being defined, and different parameter values can return different content, which is what makes a mock useful for testing branches rather than only the happy path.

Automated testing reuses the scenario tests described above. Tests can be started from the command line through Apifox CLI, and that is what makes them fit into continuous integration: a Jenkins job or any other runner can execute the collection on every build.

The database and generated code

Database access works in both directions. Data can be read from a database and used as the parameters of a request, and it can also be read to assert whether a request actually succeeded — which matters when the interface returns a small acknowledgement and the real result lands in a table.

From an interface or model definition the tool generates both business code and API request code. TypeScript, Java, Go, Swift, Objective-C, Kotlin, Dart, C++, C# and Rust are among the 130 languages and frameworks covered, and custom templates can be written so the output follows a team's own architecture conventions.

Protocols, import and export

HTTP and HTTPS interfaces are managed, and so are Socket connections over TCP. GraphQL, Dubbo, gRPC and WebSocket are stated as planned for a later release, which is worth knowing when a project is deciding whether to standardise on the tool.

Data can be exported as OpenAPI (Swagger), Markdown or HTML. Import covers OpenAPI (Swagger), Postman, HAR, RAP2, JMeter, YApi, Eolinker, NEI, RAML, DOClever, Apizza, DOCWAY, ShowDoc, apiDoc, I/O Docs, WADL and Google Discovery, so an existing collection rarely has to be rebuilt by hand.

Working as a team

Interface data is synchronised in the cloud and updates in real time, which is what makes the single-copy idea hold across several people. Permissions are managed per team and per project, with roles for administrators, ordinary members and read-only members.

Who it suits

A backend team that is tired of keeping the documentation, the debug collection and the test cases in three places gets the obvious benefit: one definition, several uses. A frontend team waiting for an interface that does not exist yet gets a mock generated from the documentation instead of a hand-written stub. And a team that already has a large collection elsewhere can usually import it rather than start again.