Rest api design
Skill kimtth/agent-skill-100-lines-or-less/skills/rest-api-design
🧿 Minimal but effective AI agent skill definitions in 100 lines or less.
npx -y skills add kimtth/agent-skill-100-lines-or-less --skill rest-api-designAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when: design RESTful HTTP APIs with correct resources, methods, status codes, and pagination.
SKILL.md
1.1 KB, as published. Nobody here has run it
Goal: HTTP APIs that follow REST conventions consumers expect.
Use for:
- designing resource-oriented HTTP endpoints
- reviewing method, status code, and URL choices
- adding pagination, filtering, and idempotency
Workflow:
- Model nouns as resources; use HTTP methods for verbs.
- Use GET (safe), POST (create), PUT/PATCH (update), DELETE.
- Return correct status codes: 2xx, 4xx for client, 5xx for server.
- Make PUT and DELETE idempotent; guard POST with idempotency keys.
- Paginate collections; support filtering and sorting via query params.
- Document the contract and version breaking changes.
Conventions:
- plural resource nouns: /users, /users/{id}/orders
- 201 + Location on create, 204 on empty success
- consistent error body with code and message
- cursor or page-based pagination, documented
Rules:
- methods match semantics; GET must not mutate
- choose status codes by meaning, not habit
- keep endpoints resource-oriented, not RPC-in-disguise
- never break URLs or shapes without versioning