agentleFS
decebalsdecebals/claude-code-java/skills/api-contract-review/SKILL.md

api-contract-review

Skill763 starsChanged 56 days agoMITView on GitHub

Review REST API contracts for HTTP semantics, versioning, backward compatibility, and response consistency. Use when user asks "review API", "check endpoints", "REST review", or before releasing API changes.

We split this skill into the rules it gives an agent

5 rules. 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 11 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before releasing API changes

    line 13
  2. Distinctive:

    Add optional field to request

    line 294
  3. Distinctive:

    Add field to response

    line 295
  4. Distinctive:

    Add new optional query parameter

    line 297
  5. Very specific:

    Check @ExceptionHandler configuration once

    line 368

“Common” is measured: kept by at least 6 in 10 of the 11 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

API Contract Review Skill

Audit REST API design for correctness, consistency, and compatibility.

When to Use

  • User asks "review this API" / "check REST endpoints"
  • Before releasing API changes
  • Reviewing PR with controller changes
  • Checking backward compatibility

Quick Reference: Common Issues

IssueSymptomImpact
Wrong HTTP verbPOST for idempotent operationConfusion, caching issues
Missing versioning/users instead of /v1/usersBreaking changes affect all clients
Entity leakJPA entity in responseExposes internals, N+1 risk
200 with error{"status": 200, "error": "..."}Breaks error handling
Inconsistent naming/getUsers vs /usersHard to learn API

HTTP Verb Semantics

Verb Selection Guide

VerbUse ForIdempotentSafeRequest Body
GETRetrieve resourceYesYesNo
POSTCreate new resourceNoNoYes
PUTReplace entire resourceYesNoYes
PATCHPartial updateNo*NoYes
DELETERemove resourceYesNoOptional

*PATCH can be idempotent depending on implementation

Common Mistakes

// ❌ POST for retrieval
@PostMapping("/users/search")
public List<User> searchUsers(@RequestBody SearchCriteria criteria) { }

// ✅ GET with query params (or POST only if criteria is very complex)
@GetMapping("/users")
public List<User> searchUsers(
    @RequestParam String name,
    @RequestParam(required = false) String email) { }

// ❌ GET for state change
@GetMapping("/users/{id}/activate")
public void activateUser(@PathVariable Long id) { }

// ✅ POST or PATCH for state change
@PostMapping("/users/{id}/activate")
public ResponseEntity<Void> activateUser(@PathVariable Long id) { }

// ❌ POST for idempotent update
@PostMapping("/users/{id}")
public User updateUser(@PathVariable Long id, @RequestBody UserDto dto) { }

// ✅ PUT for full replacement, PATCH for partial
@PutMapping("/users/{id}")
public User replaceUser(@PathVariable Long id, @RequestBody UserDto dto) { }

@PatchMapping("/users/{id}")
public User updateUser(@PathVariable Long id, @RequestBody UserPatchDto dto) { }

API Versioning

Strategies

StrategyExampleProsCons
URL path/v1/usersClear, easy routingURL changes
HeaderAccept: application/vnd.api.v1+jsonClean URLsHidden, harder to test
Query param/users?version=1Easy to addEasy to forget

Recommended: URL Path

// ✅ Versioned endpoints
@RestController
@RequestMapping("/api/v1/users")
public class UserControllerV1 { }

@RestController
@RequestMapping("/api/v2/users")
public class UserControllerV2 { }

// ❌ No versioning
@RestController
@RequestMapping("/api/users")  // Breaking changes affect everyone
public class UserController { }

Version Checklist

  • All public APIs have version in path
  • Internal APIs documented as internal (or versioned too)
  • Deprecation strategy defined for old versions

Request/Response Design

DTO vs Entity

// ❌ Entity in response (leaks internals)
@GetMapping("/{id}")
public User getUser(@PathVariable Long id) {
    return userRepository.findById(id).orElseThrow();
    // Exposes: password hash, internal IDs, lazy collections
}

// ✅ DTO response
@GetMapping("/{id}")
public UserResponse getUser(@PathVariable Long id) {
    User user = userService.findById(id);
    return UserResponse.from(user);  // Only public fields
}

Response Consistency

// ❌ Inconsistent responses
@GetMapping("/users")
public List<User> getUsers() { }  // Returns array

@GetMapping("/users/{id}")
public User getUser(@PathVariable Long id) { }  // Returns object

@GetMapping("/users/count")
public int countUsers() { }  // Returns primitive

// ✅ Consistent wrapper (optional but recommended for large APIs)
@GetMapping("/users")
public ApiResponse<List<UserResponse>> getUsers() {
    return ApiResponse.success(userService.findAll());
}

// Or at minimum, consistent structure:
// - Collections: always wrapped or always raw (pick one)
// - Single items: always object
// - Counts/stats: always object { "count": 42 }

Pagination

// ❌ No pagination on collections
@GetMapping("/users")
public List<User> getAllUsers() {
    return userRepository.findAll();  // Could be millions
}

// ✅ Paginated
@GetMapping("/users")
public Page<UserResponse> getUsers(
    @RequestParam(defaultValue = "0") int page,
    @RequestParam(defaultValue = "20") int size) {
    return userService.findAll(PageRequest.of(page, size));
}

HTTP Status Codes

Success Codes

CodeWhen to UseResponse Body
200 OKSuccessful GET, PUT, PATCHResource or result
201 CreatedSuccessful POST (created)Created resource + Location header
204 No ContentSuccessful DELETE, or PUT with no bodyEmpty

Error Codes

CodeWhen to UseCommon Mistake
400 Bad RequestInvalid input, validation failedUsing for "not found"
401 UnauthorizedNot authenticatedConfusing with 403
403 ForbiddenAuthenticated but not allowedUsing 401 instead
404 Not FoundResource doesn't existUsing 400
409 ConflictDuplicate, concurrent modificationUsing 400
422 UnprocessableSemantic error (valid syntax, invalid meaning)Using 400
500 Internal ErrorUnexpected server errorExposing stack traces

Anti-Pattern: 200 with Error Body

// ❌ NEVER DO THIS
@GetMapping("/{id}")
public ResponseEntity<Map<String, Object>> getUser(@PathVariable Long id) {
    try {
        User user = userService.findById(id);
        return ResponseEntity.ok(Map.of("status", "success", "data", user));
    } catch (NotFoundException e) {
        return ResponseEntity.ok(Map.of(  // Still 200!
            "status", "error",
            "message", "User not found"
        ));
    }
}

// ✅ Use proper status codes
@GetMapping("/{id}")
public ResponseEntity<UserResponse> getUser(@PathVariable Long id) {
    return userService.findById(id)
        .map(ResponseEntity::ok)
        .orElse(ResponseEntity.notFound().build());
}

Error Response Format

Consistent Error Structure

// ✅ Standard error response
public class ErrorResponse {
    private String code;        // Machine-readable: "USER_NOT_FOUND"
    private String message;     // Human-readable: "User with ID 123 not found"
    private Instant timestamp;
    private String path;
    private List<FieldError> errors;  // For validation errors
}

// In GlobalExceptionHandler
@ExceptionHandler(ResourceNotFoundException.class)
public ResponseEntity<ErrorResponse> handleNotFound(
        ResourceNotFoundException ex, HttpServletRequest request) {
    return ResponseEntity.status(HttpStatus.NOT_FOUND)
        .body(ErrorResponse.builder()
            .code("RESOURCE_NOT_FOUND")
            .message(ex.getMessage())
            .timestamp(Instant.now())
            .path(request.getRequestURI())
            .build());
}

Security: Don't Expose Internals

// ❌ Exposes stack trace
@ExceptionHandler(Exception.class)
public ResponseEntity<String> handleAll(Exception ex) {
    return ResponseEntity.status(500)
        .body(ex.getStackTrace().toString());  // Security risk!
}

// ✅ Generic message, log details server-side
@ExceptionHandler(Exception.class)
public ResponseEntity<ErrorResponse> handleAll(Exception ex) {
    log.error("Unexpected error", ex);  // Full details in logs
    return ResponseEntity.status(500)
        .body(ErrorResponse.of("INTERNAL_ERROR", "An unexpected error occurred"));
}

Backward Compatibility

Breaking Changes (Avoid in Same Version)

ChangeBreaking?Migration
Remove endpointYesDeprecate first, remove in next version
Remove field from responseYesKeep field, return null/default
Add required field to requestYesMake optional with default
Change field typeYesAdd new field, deprecate old
Rename fieldYesSupport both temporarily
Change URL pathYesRedirect old to new

Non-Breaking Changes (Safe)

  • Add optional field to request
  • Add field to response
  • Add new endpoint
  • Add new optional query parameter

Deprecation Pattern

@RestController
@RequestMapping("/api/v1/users")
public class UserControllerV1 {

    @Deprecated
    @GetMapping("/by-email")  // Old endpoint
    public UserResponse getByEmailOld(@RequestParam String email) {
        return getByEmail(email);  // Delegate to new
    }

    @GetMapping(params = "email")  // New pattern
    public UserResponse getByEmail(@RequestParam String email) {
        return userService.findByEmail(email);
    }
}

API Review Checklist

1. HTTP Semantics

  • GET for retrieval only (no side effects)
  • POST for creation (returns 201 + Location)
  • PUT for full replacement (idempotent)
  • PATCH for partial updates
  • DELETE for removal (idempotent)

2. URL Design

  • Versioned (/v1/, /v2/)
  • Nouns, not verbs (/users, not /getUsers)
  • Plural for collections (/users, not /user)
  • Hierarchical for relationships (/users/{id}/orders)
  • Consistent naming (kebab-case or camelCase, pick one)

3. Request Handling

  • Validation with @Valid
  • Clear error messages for validation failures
  • Request DTOs (not entities)
  • Reasonable size limits

4. Response Design

  • Response DTOs (not entities)
  • Consistent structure across endpoints
  • Pagination for collections
  • Proper status codes (not 200 for errors)

5. Error Handling

  • Consistent error format
  • Machine-readable error codes
  • Human-readable messages
  • No stack traces exposed
  • Proper 4xx vs 5xx distinction

6. Compatibility

  • No breaking changes in current version
  • Deprecated endpoints documented
  • Migration path for breaking changes

Token Optimization

For large APIs:

  1. List all controllers: find . -name "*Controller.java"
  2. Sample 2-3 controllers for pattern analysis
  3. Check @ExceptionHandler configuration once
  4. Grep for specific anti-patterns:
    # Find potential entity leaks
    grep -r "public.*Entity.*@GetMapping" --include="*.java"
    
    # Find 200 with error patterns
    grep -r "ResponseEntity.ok.*error" --include="*.java"
    
    # Find unversioned APIs
    grep -r "@RequestMapping.*api" --include="*.java" | grep -v "/v[0-9]"

Download now (ZIP)

  • Other versions11 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 1

    1. mvonline/claude-skills★ 0100% same

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use cloud-api-recipe-authoring, codebuddy-ide-mcp-upgrade and 10 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • TencentCloudBaseSkill

      cloud-api-recipe-authoring

      Author or revise a cloud-api-operations recipe (config/source/skills/cloud-api-operations/references/recipes/). Encodes why the long tail of control-plane capabilities is deliberately NOT wrapped as MCP/CLI tools, the API-first admission test for whether a capability deserves a recipe, the negative and positive lists, the fixed recipe structure, the writing rules distilled from writing-for-agents, the user-facing copy red lines, and the product regeneration/verification pipeline. Also routes contributors (and their agents) to the contribution flow and the pre-PR self-test protocol in references/contributing.md. Use when adding a recipe, judging whether a scenario belongs in the recipe set, updating the recipes index, re-checking existing recipes against the admission test, or onboarding someone who wants to submit one.

      Also in 3 projects that use this

    • TencentCloudBaseSkill

      codebuddy-ide-mcp-upgrade

      升级 CodeBuddy IDE(genie 扩展)内置的 CloudBase MCP,以及 MCP 发版时同步 IDE 侧白名单。当用户提到「更新 IDE 里的 MCP」「内置 MCP 版本太老」「IDE 集成的 CloudBase 功能不足」「改工具白名单 toolWhiteList」「把新 bundle 打进 CodeBuddy」「白名单漂移」「MCP 发版要同步什么」时使用。覆盖:解包定位内置 bundle 与内嵌配置、重新构建 mcp bundle、生成新的工具白名单与系统提示词、安全注入 IDE 并备份、用 MCP 协议验证工具清单、人工端到端验收、一键回滚。

      Also in 3 projects that use this

    • albertdobmeyerSkill

      git-workflows

      Advanced git operations beyond add/commit/push. Use when rebasing, bisecting bugs, using worktrees for parallel development, recovering with reflog, managing subtrees/submodules, resolving merge conflicts, cherry-picking across branches, or working with monorepos.

      Also in 3 projects that use this

    • ReinaMacCredySkill

      codebase-audit

      Deep codebase audit that first reads project docs (AGENTS.md, README.md) and investigates the architecture, then systematically finds hardcoded constants that should be dynamic and unfinished code (TODOs, "will"/"would" in comments). Use this skill when the user wants a thorough code review for hygiene issues, asks to find hardcoded values, wants to audit for TODOs or incomplete code, says things like "audit this codebase", "find hardcoded stuff", "what's unfinished", "find tech debt", "code hygiene check", or asks you to look across the whole project for issues. Also use when the user asks to understand a project before making changes, or wants a comprehensive health check of their codebase.

      Also in 3 projects that use this

    • Microsoft AzureSkill

      skill-authoring

      Write Agent Skills that comply with the agentskills.io specification. WHEN: "create a skill", "new skill", "write a skill", "skill template", "skill structure", "review skill", "skill PR", "skill compliance", "SKILL.md format", "skill frontmatter", "skill best practices". DO NOT USE FOR: general documentation. INVOKES: vally CLI.

      Also in 5 projects that use this

    • +7 more from TencentCloudBase
  • In this repository17 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.