Validation and errors
Connect a schema validator
Use a schema library when it improves reuse and types without hiding the actual HTTP failure contract.
9 minute lesson
Start from the behavior you can observe. The create schema validates URL and title shape; the service checks whether the normalized URL already exists.
A schema can validate structure and infer types, but the route still owns error status, field reporting, and business rules. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.
It is tempting to put database lookups and authorization side effects inside a reusable structural schema. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to separate structural validation from contextual business checks and translate issues into a stable client response. Make the boundary explicit in code and in the project notes.
Tie the decision back to the larger job: Reject malformed or unauthorized requests at the boundary and keep domain code independent of raw request parsing. Record enough evidence that another developer can repeat the result without relying on your memory.
Test malformed JSON, invalid URLs, duplicate normalized URLs, and an unknown field according to the documented policy. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.
Lesson completed