REST and JSON API Performance Testing: Configuration, Design Patterns, and Trade-Offs

1. Mandatory path remains local/free

2. Resource-level versus end-to-end transaction tests

It is valid to keep both in one plan/report if labels are explicit, but never quote the transaction p95 as “GET latency.”

3. Shared versus per-user data

Shared immutable data is efficient for read-only GET scenarios where many users legitimately read the same public/catalog record. Per-user mutable data is safer for update/delete/write scenarios because each thread owns its object and correlation ID.

Sharing one mutable resource is justified only if production users truly contend on that same resource and the contention itself is the workload objective.

4. Setup API calls versus pre-seeded fixtures

A Setup Thread Group can create run data, but variables are thread-group local. If it produces IDs needed by another Thread Group, use an explicit safe handoff store/file/property only when the ownership model is clear. For beginner labs, keep per-user creation in the same thread when correlation is needed.

5. Idempotent per-item cleanup versus teardown sweep

Per-item DELETE immediately after use minimizes target leakage and attributes cleanup failures to a resource. A final run-scoped sweep is a safety net for interrupted/failing iterations. The best checkpoint uses both:

1. normal flow deletes ${ITEM_ID};
2. post-run cleanup targets only ${RUN_ID};
3. verification proves zero remaining run-scoped resources.

Never use an unscoped destructive sweep in a shared environment.

6. Teardown script/controller trade-off

A tearDown Thread Group can run cleanup after ordinary Thread Groups, but thread-local variables from workload threads are not automatically available there. A run-scoped cleanup endpoint avoids needing to transfer every ITEM_ID and remains bounded to one synthetic run.

If the generator crashes or is killed, even tearDown logic may not run. Operational cleanup must therefore also be runnable independently using the stored RUN_ID.

7. Response-body validation depth versus generator cost

Use the smallest assertions that prove the load test is exercising the intended success path. Keep fuller schema/property tests in a separate functional/API test layer unless they are essential to load validity.

8. JSONPath versus JMESPath

JMeter provides both JSON Extractor/Assertion (JsonPath) and JSON JMESPath Extractor/Assertion. This chapter uses JMESPath for simple scalar fields such as item.id, status, and item.version. Use one team-standard query language consistently where possible.

Current JSON assertions first parse the body and fail if it is not valid JSON; missing paths are also failures before optional expected-value comparison.

9. Header scope and authentication boundary

Content-Type: application/json belongs to JSON-body operations; Accept: application/json is broader. Authentication is intentionally absent from the Chapter 14 mandatory lab. Chapter 15 introduces authentication/tokens/session workflows.

If a real authorized API requires credentials, use a secure external secret mechanism and synthetic/non-production account; do not hard-code bearer/API keys into JMX or HTML lessons.

10. Retry policy is operation-semantic, not universal

GET may be naturally safe to retry from a resource-state perspective, while POST may create a duplicate if the first response is lost after server commit. Blindly retrying writes can change the workload and corrupt test data.

If production supports idempotency keys, model them explicitly in the authorized environment. This chapter does not invent a retry layer; it preserves first failure and cleans by run ID.

11. Result schema and dashboard

Keep stable labels such as Create Item, Read Item, Update Item, Delete Item, and Resource Lifecycle. CSV JTL should retain label, elapsed, success, response code/message, thread counts, and assertion failure messages. Generate dashboard after/at CLI run and inspect operation-level statistics/errors.

Do not save full successful response bodies in high-load CSV; current CSV output does not store response data by default. Sensitive response retention should be opt-in, bounded, and reviewed.

12. Configuration-layer boundaries

13. Worked scenario

Decision: “We need a release gate for catalog GET latency and a separate sanity gate proving create/update/delete still works under low concurrency.”

• Pre-seed 10 immutable synthetic catalog items → GET-only timed profile; random/partitioned reads; status + key JSON assertions.
• Separate 1–2 thread lifecycle profile → each thread creates/updates/deletes its own item tagged with RUN_ID.
• Do not mix write lifecycle samples into the GET latency population.
• Require zero leaked RUN_ID resources before declaring the run valid.

14. Evidence contract

For every meaningful run preserve raw JTL + matching jmeter.log, exact JMX/properties/RUN_ID, fixture version/schema, event log/metrics, generator CPU/memory, and cleanup verification. Configured thread/duration settings without achieved sample counts are insufficient.

15. Decision table

Knowledge check

Official references and version notes

• Component Reference — HTTP Request, Header Manager, JSON/JSON JMESPath Extractor, JSON/JSON JMESPath Assertion, Response Assertion, Transaction Controller, and related core semantics.
• Elements of a Test Plan — scope/execution order and variable behavior.
• Getting Started — GUI authoring/debugging versus CLI load execution.
• Generating Dashboard Report — CSV result requirements, statistics, request summary, and error tables.
• Properties Reference — result-save fields including assertion failure messages.
• Best Practices — CLI execution, lean listeners, and injector validity.
• Apache JMeter downloads — current stable release and Java requirement.