ICT-App Dev Specialist FA study materials
ICT-App Dev Specialist FA study resources

ICT-App Dev Specialist FA flashcards

ICT-App Dev Specialist FA · Build recall with a focused review session.

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

HTTP status 201
Returned after a successful create request; the response typically includes a Location header pointing to the new resource and sometimes the created representation itself.
Idempotent HTTP method
A method whose repeated identical requests leave the server in the same state; GET, PUT, and DELETE are idempotent, while POST usually is not.
REST resource naming
URLs name resources with plural nouns and no verbs, such as /orders/17/items; the action is expressed by the HTTP method rather than the path.
401 versus 403
401 Unauthorized means credentials are missing or invalid, so the client should authenticate; 403 Forbidden means identity is known but permission is denied.
JWT structure
Three base64url parts separated by dots: header (algorithm and type), payload (claims such as sub and exp), and signature that the server verifies.
SQL injection prevention
Use parameterized or prepared statements so user input is bound as data, never concatenated into SQL text; add least-privilege database accounts as defense in depth.
Cross-site scripting (XSS)
Injection of executable script into pages viewed by other users; prevented by context-aware output encoding, input validation, and a restrictive Content-Security-Policy header.
Cross-site request forgery
An attacker makes a victim's browser send an authenticated state-changing request; mitigated with anti-CSRF tokens and SameSite cookie attributes.
CORS preflight
For non-simple cross-origin requests the browser first sends an OPTIONS request; the server must reply with Access-Control-Allow-Origin and allowed methods and headers.
Unit test
A fast, isolated test of one function or class with dependencies replaced by stubs or mocks; it pinpoints failures precisely and forms the base of the test pyramid.
Integration test
A test that exercises two or more real components together, such as code plus database or API plus service, to verify contracts and data flow between modules.
End-to-end test
A test driving the full system through its real interface, from UI to database; slow and brittle, so reserved for critical user journeys.
Test pyramid
A guidance model with many fast unit tests at the base, fewer integration tests in the middle, and few slow end-to-end tests at the top.
Mock versus stub
A stub returns canned answers to calls; a mock additionally records interactions and lets the test assert that specific calls happened with expected arguments.
Regression test
A test added or kept to confirm that a fixed defect or new change does not break previously working behavior.
Code coverage
The percentage of code lines or branches executed by tests; useful as a gap indicator but not proof of correctness, since assertions may be weak.
Dependency injection
A pattern where a class receives its collaborators from outside instead of constructing them, enabling substitution in tests and reducing coupling.
MVC pattern
Model holds data and rules, View renders presentation, Controller handles input and coordinates the two; separates concerns so UI changes do not touch business logic.
Single responsibility principle
A class or module should have one reason to change, meaning one cohesive job; it limits the blast radius of modifications.
Interface segregation principle
Clients should not depend on methods they do not use; split large interfaces into smaller role-specific ones so implementers need not stub irrelevant members.
Liskov substitution principle
Subtypes must be usable wherever the base type is expected without breaking correctness; overridden methods must honor the base contract, including preconditions and postconditions.
Open-closed principle
Software entities should be open for extension but closed for modification; new behavior arrives through new implementations rather than edits to tested code.
Dependency inversion principle
High-level modules should depend on abstractions, not concrete details; both sides depend on interfaces, which inverts the direction of source dependencies.
Git merge versus rebase
Merge joins histories with a merge commit preserving both lines; rebase replays commits onto a new base for a linear history but rewrites commit hashes.
Pull request review
A pre-merge review of a branch's diff where peers check correctness, security, and style; it is a quality gate, not a replacement for automated tests.
Semantic versioning
Version numbers MAJOR.MINOR.PATCH: MAJOR for breaking changes, MINOR for backward-compatible features, PATCH for backward-compatible fixes.
Continuous integration
Every push triggers automated build and test runs on a shared branch, catching integration defects early and keeping the mainline releasable.
Continuous delivery
The pipeline always produces a deployable artifact and deployment is a routine, automated step requiring only a manual approval decision.
Feature flag
A runtime switch that enables or disables code paths without redeploying, allowing gradual rollout and instant rollback of risky changes.
Blue-green deployment
Two identical environments where traffic switches from the live one to the updated one; rollback is a switch back, minimizing downtime.
Canary release
New version is exposed to a small slice of traffic first; error and latency metrics are compared before widening the rollout.
Database transaction ACID
Atomicity, Consistency, Isolation, Durability: a transaction either fully commits or fully rolls back and survives failures once committed.