Standard API Response and Error
Because who doesn't love standardized responses? Let's make your API responses as predictable as your morning coffee routine.
Installation
npx vynk add api-response-and-error
yarn vynk add api-response-and-error
pnpm dlx vynk add api-response-and-error
bunx --bun vynk add api-response-and-error
ApiResponse
Ah, the ApiResponse class - your API's way of saying "I'm not dead, I promise!" This class is like that friend who always responds to your texts, even if it's just to say "k".
Usage
import { ApiResponse } from '@/utils/apiResponse'
// When everything goes right (which is never, but let's pretend)
const successResponse = new ApiResponse(200, { data: "I'm working, I swear!" })
// When you're not sure what's happening (which is always)
const confusedResponse = new ApiResponse(418, null, "I'm a teapot, not a coffee maker!")Props
| Prop | Type | Description |
|---|---|---|
statusCode | number | The HTTP status code that tells your frontend whether to celebrate or cry |
data | Record<string, unknown> | null | The actual data (if any) that your frontend will probably ignore anyway |
message | string | A friendly message that no one will read |
success | boolean | A boolean that's automatically set based on whether your status code is less than 400 (because who needs explicit success flags?) |
ApiError
Meet ApiError, the class that makes your frontend developers cry. It's like Error, but with extra steps and more ways to tell you that something went wrong.
Usage
import { ApiError } from '@/utils/apiError'
// When your database is having an existential crisis
const dbError = new ApiError(500, "The database is questioning its life choices")
// When your user tries to access something they shouldn't
const authError = new ApiError(403, "Nice try, but you're not getting in here", ["Missing permissions", "Invalid token"])Props
| Prop | Type | Description |
|---|---|---|
statusCode | number | The HTTP status code that tells your frontend exactly how much trouble they're in |
message | string | A message that will make your users feel bad about themselves |
success | boolean | Always false because if it was true, you wouldn't be using this class |
errors | string[] | An array of additional error messages, because one error is never enough |
Why Use These?
- Consistency: Because nothing says "professional" like consistent error messages
- Type Safety: TypeScript will yell at you if you try to do something stupid (which you probably will)
- Debugging: When things go wrong (and they will), you'll know exactly who to blame
- User Experience: Your users will love getting the same error message in 50 different ways
Best Practices
- Always use meaningful status codes (because 418 is more fun than 400)
- Keep error messages short and sweet (or long and passive-aggressive)
- Use the
errorsarray to list every single thing that went wrong (your users love reading) - Remember: if your API is working perfectly, you're probably doing something wrong
Example
// The perfect API response (it doesn't exist, but we can dream)
const perfectResponse = new ApiResponse(200, {
data: "Everything is working as expected",
timestamp: new Date().toISOString(),
unicorns: "🦄"
})
// The reality (this is what you'll actually get)
const reality = new ApiError(500, "The server is having a bad day", [
"Database connection failed",
"Cache is having an existential crisis",
"The coffee machine is broken"
])Remember: in the world of APIs, the only constant is that something will always go wrong. But with these classes, at least it'll go wrong in a standardized way! 🎉