Connecting the app to the data · Connexion de l'application aux données
| English | Français |
|---|---|
| parameterised query/ˌpærəˈmetəraɪzd ˈkwɪərɪ/ | requête paramétrée |
A valid ID can still request private data
- A student ID can be a valid integer and still belong to someone else. Input validation alone must not unlock a private course list.
- For this route, an authenticated student may read only their own list. Resolve the caller’s identity and enforce that policy before fetching the private rows.
A submitted student ID has the right type. What must still be checked for a private lookup?
Correct shape does not establish access.
Fetch only the permitted rows and fields
- A parameterised query 参数化查询 binds the permitted student ID as data. Select only the fields the interface needs, such as course ID and title.
- Do not download private records for every student and hide unwanted ones in the browser. The recipient could inspect the full response.
Why must private records for every student not be sent and merely hidden by browser filtering?
Enforce private data access on the server before returning rows.
Define empty and denied responses
- In this contract, a permitted student with no courses receives 200 and
[]. A nonexistent resource or denied caller follows the agreed API policy. - Some policies use 404 to avoid revealing private existence. Keep that policy consistent; do not use a success response to disguise an unexpected database failure.
Under this route contract, a permitted student exists but has no courses. Which response is appropriate?
A successful empty list is a defined outcome, not a database failure.
Render the response without confusing states
- On success, render the selected course titles as text. Show “No courses yet” only after a successful empty response.
- During loading, show that the request is pending. On failure, explain that the list could not be loaded and offer an appropriate retry; do not claim the list is empty.
Write separate messages for a successful empty list and a failed request.
“No courses yet” differs from “Could not load courses. Try again.”
Match response progress to display.
Display only what the observed outcome supports.
Handle a change without half-saving it
- A write involving several related database changes may need a transaction: commit the intended changes together or roll them back on failure.
- Validate and authorize the write independently. A successful earlier read does not authorize every later change or make a dropdown value safe to paste into SQL.
A dropdown value is safe to paste into SQL because users cannot send other values.
Callers can send altered requests. Bind the value and validate it on the server.
Related writes may need a transaction so a failure does not leave half the intended changes saved.
A transaction can commit the intended group or roll it back; validation and authorization are still required.
Review the full permitted journey
- Trace identity and permission → valid input → parameterised lookup → defined response → honest display. Test denied access before checking the display.
- Use fixtures for an ordinary list, an empty list and a failed request. Confirm that private fields and other students’ rows are absent from permitted responses.
A correct query is part of a correct route. The caller, allowed data, response contract and visible state must also agree.
Order this permitted course-list workflow.
The server’s checks precede retrieval and delivery.