Front end and back end · Front-end e back-end
| English | Português |
|---|---|
| request/rɪˈkwest/ | solicitar |
| front end/frʌnt end/ | front end |
| back end/bæk end/ | back end |
| server/ˈsɜːvə/ | servidor |
| response/rɪˈspɒns/ | resposta |
| API/ˌeɪ piː ˈaɪ/ | API |
| JSON/ˈdʒeɪsn/ | JSON |
A learner changes the number in the URL
- A course page requests
/students/42/courses. A visitor changes 42 to 43. Hiding that link on the screen does not prevent the request. - The · A front end 前端 displays the interface. The back end 后端 runs on a server 服务器 and processes a request 请求 before sending a response 响应.
Agree what each request means
- An API 应用程序接口 defines how software communicates. A contract states the method, path, input, allowed caller, response fields and failure behaviour.
- For a student-only course list, the server must identify the caller and check permission. A number supplied by the browser is not proof of identity.
The browser asks for student 43. What proves the caller may read that list?
An ID selects a resource; it is not proof of identity or permission.
Read the response as data
- JSON 数据交换格式 can represent objects, arrays, strings, numbers, booleans and null. It is common in web APIs, but not every response uses it.
- A successful list might be
[{"course_id":7,"title":"Robotics"}]. An empty permitted list can be[]; neither result tells the browser to execute code.
Which common data format is represented by [{"course_id":7,"title":"Robotics"}]?
This is JSON: an array containing an object.
Place each rule where it can be enforced
- Browser validation gives quick feedback, but the server must check input and permission independently. A caller can send requests without using your form.
- Keep database passwords and private API credentials on the server. A user may type a login password into a browser; transmit it securely and never embed a private service credential in downloadable code.
Where should a private database password used by the application be kept?
Downloadable code can be inspected. Keep private service credentials on the server.
The server needs independent input checks even when the form validates input.
A caller can bypass the form and send a request directly.
Explain why browser validation cannot replace server checks.
A caller can send a request without the form, so the server checks it independently.
Show loading, success and failure honestly
- While the request is pending, show a loading state. After success, show the returned courses or an empty-list message.
- A failed request needs a useful failure state. Do not label a network failure “no courses”: the server has not confirmed an empty result.
Match each outcome to an honest display.
An unconfirmed result must not be displayed as an empty successful list.
Trace the whole interaction
- Trace: browser request → server input and permission checks → permitted data lookup → response → browser display. Stop the lookup when a required check fails.
- Test an allowed caller, a denied caller, an empty result and a failed request with local fixtures. Do not expose another student’s data to test access.
The browser helps the user; the server enforces the rule. Identity, permission, valid input and a successful lookup are separate checks.
Order this successful permitted lookup.
The server enforces the rule before returning private data.
Every web API response must use JSON.
JSON is common, but APIs can use other documented formats.