La API navegable y los códigos de estado

DRF's browsable API renders any endpoint as an interactive web page, so you can explore and test your API without extra tools. 🌐

DRF uses content negotiation: browsers ask for HTML and get the friendly page, while code asking for JSON gets raw JSON instead.

For write endpoints the browsable API even shows a form, letting you POST test data with a click instead of crafting curl commands.

Append ?format=json to any URL to skip the HTML page and see the exact JSON a real client would receive.

Every API response carries an HTTP status code that tells the client what happened, far more reliably than reading the body text.

200 means a successful read, while 201 Created signals that a POST actually made a new resource, a small but important distinction.

Instead of magic numbers, DRF gives you named constants in status so your code reads clearly and avoids typos like 20 versus 200.

The 4xx range blames the request: 400 means bad input that failed validation, and 404 means the resource simply was not found.

A 500 means your code crashed, not the client. These signal bugs to fix, never something the caller did wrong.

Good APIs are predictable: return 201 on create, 400 on invalid input, 404 when missing. Correct status codes make clients trust you.

Together the browsable API and clear status codes make DRF endpoints easy to test by hand and easy for clients to consume.

Which status code best fits a successful POST that creates a record?

You met the browsable API for hands-on testing and learned to return honest status codes like 200, 201, 400, and 404. ✅