As a backend developer, try to follow these 12 API design best practices(also often asked in interviews):
1. Clear Resource Names
> Bad (verb): GET /get-all-orders
> Good (noun): GET /orders
2. Standard Methods
> Use POST /users to create a new user.
> Use GET /users/123 to retrieve user 123.
> Use PUT /users/123 to replace user 123.
> Use DELETE /users/123 to delete user 123.
3. Idempotency
> Client sends a POST /payments request with a unique header: Idempotency-Key: abc-123. If the client's network disconnects and sends the exact same request again, the server sees abc-123, recognizes it, and returns the original success response without charging the card a second time.
4. API Versioning
> Place the version in the URL path, as it's the clearest method for clients.
>> GET /v1/products/42 (Old version)
>> GET /v2/products/42 (New version)
5. Correct Status Codes
> When a client requests GET /user/999 and that user doesn't exist, return a 404 Not Found status, not a 200 OK status with an {"error": "user not found"} body.
6. Pagination
> For a request like GET /articles?page=2&limit=50, the API should return articles 51 through 100.
7. Filtering & Sorting
> To find all "shipped" orders and sort them by the newest first, a client would request:
>> GET /orders?status=shipped&sort=-created_at
8. Security
> To access their profile, a client must send a request with an Authorization header containing a valid JSON Web Token (JWT).
>>Authorization: Bearer <long_encrypted_token_string>
9. Rate Limiting
> A user is allowed 100 requests per minute. When they make the 101st request in that minute, the server denies it and returns a 429 Too Many Requests status code.
10. Caching
> When a client requests GET /blog/posts/123, the server returns the post along with an ETag: "abc" header. When the client requests it again, it sends If-None-Match: "abc", and the server replies with 304 Not Modified (and an empty body) because the content hasn't changed.
11. API Docs
> Providing an interactive Swagger UI or OpenAPI webpage that lists all endpoints (like /users, /orders), shows request/response models, and lets developers try the API directly from their browser.
12. Pragmatic
Even though REST principles suggest nouns, an endpoint like POST /auth/login is often clearer and more practical than a "pure" RESTful endpoint like POST /sessions.
Jadi ayah. Punya anak.
Tiba tiba berasa punya tanggung jawab yang bakal dipikul sampe mati.
Apa berat? Berat. Gausab bla bla bla "kalo ikhlas ga berasa berat" atau "berat tuh karena ga tulus"
Engga. Emang berat. Memastikan keturunan lo dapet segala sesuatu yg cukup dan memadai itu berat.
Kalo mau ringan lo pelihara hamster aja.