🔍 REST API Audit Report

Full analysis of every violation with corrected endpoints and REST principles

Overall API Health Score
4/100
4 Endpoints Audited 15 Violations Found 0 Correct Endpoints 4 Fixed Endpoints
📋 Endpoint-by-Endpoint Analysis
GET /getUsers 4 problems
▼

❌ ORIGINAL

GET /getUsers

✅ CORRECTED

GET /users
Violated: Resource Naming Violated: Noun-Only URIs Violated: Plural Collections Violated: No Verb in Path

Problems Identified

🔴 Verb in URI: "get" is embedded in the path. REST URIs must identify resources, not actions. The HTTP method (GET) already communicates the action — duplicating it in the path is redundant and violates the uniform interface constraint.
🔴 Camel case naming: "getUsers" mixes a verb prefix with a noun using camelCase. REST URI conventions use lowercase kebab-case (e.g., /user-profiles) or simple lowercase nouns.
🔴 Singular vs. Plural inconsistency risk: While the word "Users" is plural here, the pattern set by this endpoint is inconsistent with the other endpoints which use singular "user". Collections should always be plural nouns: /users.
🔴 RPC-style design: This endpoint reads like a remote procedure call (getUsers()) rather than a REST resource. REST is resource-oriented, not action-oriented.

✅ Why the Fix is Correct

GET /users — The HTTP verb GET already declares the intent to retrieve. The URI /users identifies the resource collection (plural noun, lowercase). No verb needed, no ambiguity.

To retrieve a specific user: GET /users/{id}. To filter: GET /users?role=admin&status=active.

POST /user/delete/5 5 problems
▼

❌ ORIGINAL

POST /user/delete/5

✅ CORRECTED

DELETE /users/5
Violated: Correct HTTP Method Violated: No Verb in Path Violated: Plural Collections Violated: Idempotency Semantics Violated: Uniform Interface

Problems Identified

🔴 Wrong HTTP method: POST is used for creating new resources or submitting data. Deletion must use the DELETE method. Using POST for deletion breaks the HTTP specification's semantic contract and makes the API unpredictable to clients, proxies, and caches.
🔴 Verb in URI ("delete"): The action "delete" is baked into the path. This is the most common REST anti-pattern. The DELETE HTTP method communicates this intent. The path should only identify the resource: /users/5.
🔴 Singular resource name: /user/ uses a singular noun for a collection segment. REST convention requires plural nouns for collections: /users/. Singular is only used when the resource is a singleton (e.g., /users/5/profile).
🔴 Broken idempotency: DELETE must be idempotent — calling it multiple times must produce the same result (resource stays deleted). POST is explicitly non-idempotent. Using POST for deletion breaks this guarantee and confuses caching layers and retry logic.
🔴 Inconsistent naming with other endpoints: This uses /user/ while endpoint 1 uses /getUsers. The collection path must be consistent across all operations on the same resource type.

✅ Why the Fix is Correct

DELETE /users/5 — DELETE is the correct HTTP method for removal. It is idempotent (calling it twice is safe). The URI /users/5 cleanly identifies the specific resource: user with ID 5, inside the users collection.

Expected responses: 204 No Content on success, 404 Not Found if user doesn't exist, 409 Conflict if deletion is blocked by a dependency.

GET /createUser?name=Jo 4 problems
▼

❌ ORIGINAL

GET /createUser?name=Jo

✅ CORRECTED

POST /users Body: { "name": "Jo" }
Violated: Correct HTTP Method Violated: No Verb in Path Violated: Safe Method Semantics Violated: Data in Request Body

Problems Identified

🔴 GET used for a state-changing operation: GET is a safe method — it must never modify server state. Creating a resource is a state change. This must use POST. Using GET to create data means browsers, crawlers, and prefetch mechanisms can accidentally trigger resource creation.
🔴 Verb in URI ("createUser"): Same violation as endpoint 1. "create" is an action, not a resource. The POST method to a collection URI (/users) already communicates "create a new user in this collection".
🔴 Resource data in query string: Sending ?name=Jo in a GET request exposes resource data in the URL. This data will appear in server logs, browser history, and referrer headers — a security and privacy risk. Creation data belongs in the request body of a POST request.
🔴 Cacheable mutation: GET responses are cached by browsers and proxies. A GET that creates a resource could be cached and replayed, causing duplicate resource creation or stale "creation" responses being served from cache.

✅ Why the Fix is Correct

POST /users with body {"name": "Jo"} — POST to a collection creates a new member. Data travels in the request body (not the URL), keeping it out of logs and caches. POST is non-idempotent, which correctly signals that each call may create a new resource.

Expected responses: 201 Created with a Location: /users/6 header pointing to the new resource, plus the created resource in the body.

PUT /updateAllUsers 4 problems
▼

❌ ORIGINAL

PUT /updateAllUsers

✅ CORRECTED

PATCH /users Body: { "status": "inactive" }
Violated: Correct HTTP Method Violated: No Verb in Path Violated: PUT Semantics Violated: Bulk Operation Pattern

Problems Identified

🔴 Wrong HTTP method (PUT vs PATCH): PUT requires sending the complete replacement representation of a resource. Using PUT on a collection to "update all" would mean replacing the entire collection with a new one — almost certainly not the intent. PATCH is correct for partial updates, including bulk partial updates to a collection.
🔴 Verb in URI ("update"): "update" is an action. The PATCH/PUT method already communicates modification intent. The URI should identify the resource being modified: /users (the collection).
🔴 Ambiguous scope ("All"): "updateAllUsers" encodes business logic scope into the URI. In REST, scope is controlled through query parameters: PATCH /users (all), PATCH /users?status=active (filtered subset). Encoding scope in the URI path creates an explosion of endpoint variants.
🔴 Naming inconsistency: camelCase "updateAllUsers" is inconsistent with REST URI conventions (lowercase, hyphen-separated) and inconsistent with the other endpoints in this API, making the API harder to predict and consume.

✅ Why the Fix is Correct

PATCH /users with a partial update body — PATCH applies partial modifications. Applied to the collection URI /users, it signals a bulk partial update. Filters can be added via query params: PATCH /users?department=engineering.

If truly replacing all users with a complete new dataset, use PUT /users with the full collection in the body. Expected responses: 200 OK with update summary, or 204 No Content.

📊 Issue Summary
15 Total Violations
4 Wrong HTTP Methods
4 Verbs in URIs
0 Correct Endpoints
Endpoint Violation Category Severity
GET /getUsers Verb "get" in URI path Resource Naming High
GET /getUsers camelCase URI naming Naming Convention Medium
GET /getUsers RPC-style design Architecture High
GET /getUsers Inconsistent plural naming vs other endpoints Consistency Medium
POST /user/delete/5 POST used instead of DELETE HTTP Method High
POST /user/delete/5 Verb "delete" in URI path Resource Naming High
POST /user/delete/5 Singular "user" instead of plural "users" Naming Convention Medium
POST /user/delete/5 Broken idempotency semantics HTTP Semantics High
POST /user/delete/5 Inconsistent collection name vs endpoint 1 Consistency Medium
GET /createUser?name=Jo GET used for state-changing operation HTTP Method High
GET /createUser?name=Jo Verb "create" in URI path Resource Naming High
GET /createUser?name=Jo Resource data exposed in query string Security / Data Handling High
GET /createUser?name=Jo Mutation via cacheable GET request HTTP Semantics High
PUT /updateAllUsers PUT used instead of PATCH for partial update HTTP Method High
PUT /updateAllUsers Verb "update" + scope "All" in URI path Resource Naming High
📚 REST Principles Violated in This API

🔤 1. Resources, Not Actions — URIs Are Nouns

URIs identify resources (things), not operations (actions). Actions are expressed through HTTP methods. A URI like /deleteUser or /getUsers encodes the action in the path — this is an RPC pattern, not REST. Every endpoint in this API violates this principle. Correct: GET /users, DELETE /users/5.

🔧 2. HTTP Method Semantics Must Be Honoured

GET = safe + idempotent, retrieves state, never modifies it.
POST = creates a new resource in a collection, non-idempotent.
PUT = replaces a resource completely, idempotent.
PATCH = partially updates a resource, not necessarily idempotent.
DELETE = removes a resource, idempotent.
Using POST to delete, or GET to create, breaks the HTTP contract that clients, proxies, and caches rely on.

📦 3. Plural Nouns for Collections

Collections are plural: /users, /orders, /products. Individual resources are addressed by ID within the collection: /users/5. Mixing singular and plural (/user vs /users) across endpoints for the same resource type breaks consistency and predictability.

🔒 4. Safe and Idempotent Method Guarantees

Safe methods (GET, HEAD, OPTIONS) must not change server state. Browsers, prefetch engines, and link crawlers call GET freely. A GET that creates data is a security and data integrity disaster.
Idempotent methods (GET, PUT, DELETE, HEAD) must produce the same result when called multiple times. This enables safe retries. POST and PATCH are not idempotent by definition.

🔗 5. Uniform Interface

One of REST's core constraints. The interface between client and server must be uniform and predictable. This means consistent resource naming, consistent use of HTTP methods, consistent response structures, and consistent use of status codes. An API where you must read documentation for every endpoint because each follows different conventions is not RESTful.

🔍 6. Query Parameters for Filtering, Not Scoping Actions

Query parameters filter, sort, or paginate a resource collection. They should not encode business logic scope into the URI path. /updateAllUsers encodes "all" as scope in the path. The REST way: PATCH /users (all), PATCH /users?status=active (filtered). This avoids URI proliferation.

📨 7. Resource Data Belongs in the Request Body

Data used to create or update a resource belongs in the request body, not the URL. Query strings are for filtering/sorting existing resources. Putting creation data in a GET query string (?name=Jo) exposes sensitive data in server logs, browser history, and referrer headers, and breaks caching semantics.

📝 8. Consistent URI Naming Conventions

REST URIs should use: lowercase letters, hyphens (not underscores or camelCase) for multi-word names, no trailing slashes, and no file extensions. Examples: /user-profiles not /userProfiles or /user_profiles. Consistency across the entire API is more important than any single convention choice.

⚙️ HTTP Methods Quick Reference
Method Purpose Safe? Idempotent? Request Body? Success Code
GET Retrieve a resource or collection ✔ Yes ✔ Yes ✘ No 200 OK
POST Create a new resource in a collection ✘ No ✘ No ✔ Yes 201 Created
PUT Replace a resource completely ✘ No ✔ Yes ✔ Yes 200 OK / 204
PATCH Partially update a resource ✘ No ✘ No* ✔ Yes 200 OK / 204
DELETE Remove a resource ✘ No ✔ Yes ✘ No 204 No Content

* PATCH can be made idempotent depending on implementation (e.g., set operations vs. increment operations).

📋 Corrected API at a Glance
Operation Original (Wrong) Corrected
List all users GET /getUsers GET /users
Get one user Not provided GET /users/{id}
Create a user GET /createUser?name=Jo POST /users
Replace a user Not provided PUT /users/{id}
Partially update a user Not provided PATCH /users/{id}
Bulk partial update PUT /updateAllUsers PATCH /users
Delete a user POST /user/delete/5 DELETE /users/5