Rest Api Design
CheckedHelps with REST APIs, API, design as part of developing backend services and APIs workflows.
Install on your platform
Showing Claude Code. One command installs this skill into any of the agents below.
- 1
Run this in your project
terminal$ npx skills add secondsky/claude-skills --skill rest-api-design -a claude-code Uses the open-source
skillsCLI and needs Node.js. Add-gto install it for your user instead of this project.
What we know about this skill
Publisher
secondsky
Taken from the source listing. We haven't verified who controls this account.
Install target
Live repository
Not pinned. Installing fetches whatever the repository holds at the time you run the command.
Automated safety checks
This skill passed all 6 checks. We read its files at one commit and looked for the things that make a skill dangerous to run — not for whether it works.
Declares what it does: passed
SKILL.md parses and declares a name and a description.
SKILL.md exists, its frontmatter parses, and it declares a name and a description.
No undeclared network calls: passed
Makes no network calls.
Every host the skill dials — from its scripts, its config endpoints or the commands it tells the agent to run — is either well-known package and API infrastructure or declared in its own frontmatter. Links in documentation are not counted.
No obfuscated payloads: passed
No encoded or obfuscated payloads.
No base64, hex or compressed blob is decoded and then executed, and no encoded shell commands.
No credential access: passed
Reads no keys, tokens, keychains or credential files.
Neither the code nor the SKILL.md instructions read SSH keys, cloud credentials, keychains, token stores, browser cookie databases or dotfiles that hold secrets.
No pipe-to-shell installers: passed
No pipe-to-shell or download-and-run installers.
No `curl … | sh` pattern, in the code or in the instructions, that runs code fetched at run time.
Pinned to a commit: passed
Scanned secondsky/claude-skills at 8837836131.
The exact upstream commit SHA that was scanned is recorded, so the result refers to specific bytes.
- Commit
- 8837836131
- Scanned
- 1 file, 95 lines
About this skill
What it does
This skill assists in designing RESTful APIs, focusing on proper conventions and a positive developer experience. It provides guidance on resource naming (using nouns), appropriate HTTP methods for different actions (GET, POST, PUT, PATCH, DELETE), standard status codes, response formatting including data, meta information, pagination, and query parameters. The goal is to help create well-structured and documented backend APIs.
When to use it
- When designing new REST APIs or microservices.
- To review existing API designs for adherence to RESTful principles.
- For guidance on choosing the correct HTTP methods (GET, POST, PUT, PATCH, DELETE) for specific actions.
- To understand and implement proper status code usage in API responses.
- When implementing pagination or filtering of data returned by an API endpoint.
Key capabilities
- Resource Naming: Guidance on using nouns instead of verbs in resource URLs (e.g.,
/api/usersvs./api/getUsers). - HTTP Methods: Explanation and use cases for GET, POST, PUT, PATCH, and DELETE methods.
- Status Codes: Provides a reference for common HTTP status codes (200, 201, 204, 400, 401, 403, 404, 429) and their appropriate usage.
- Response Formatting: Examples of response formats including data sections, meta information, and pagination details.
- Query Parameters: Demonstrates how to use query parameters for filtering, sorting, pagination, and field selection.
Example prompts
- "I need help designing an API endpoint for creating new users. What HTTP method should I use?"
- "What are some best practices for naming resources in a RESTful API?"
- "Can you show me an example of a response format including pagination?"
- "What status code should I return when a resource is successfully deleted?"
Tips & gotchas
- The skill focuses on RESTful design principles and doesn't cover implementation details or specific programming languages.
- Version your APIs using URL paths (e.g.,
/api/v1/) for backwards compatibility. - Consider documenting your API with OpenAPI/Swagger for improved developer understanding.