the API vs system-call distinction
When you write code, you almost never make a raw system call yourself; you call a friendly function from a library, and that function reaches the kernel for you. The distinction between the API you call and the system call underneath is a frequent source of beginner confusion, and clearing it up explains how programs really talk to the OS. Picture ordering food through a delivery app: you tap a tidy button (the API), and behind the scenes the app phones the restaurant and arranges a driver (the system calls). You interact only with the button; the messy real work happens out of sight.
An API (application programming interface) is the set of functions a programmer is given to call, with defined names, parameters, and return values — for example the C standard library's fopen and fread, or a language's file-reading functions. A system call is the actual request into the kernel. Often one API function maps to one system call (the library's read wrapper essentially triggers the read system call). But the mapping is not one-to-one: a single API call like fprintf may buffer your text and issue a real write system call only occasionally, and some API functions (like sorting an array in memory) make no system call at all because they need no kernel help. The API is the contract you program against; the system call is the mechanism that crosses into the kernel when crossing is actually needed.
Why prefer the API over calling the system call directly? Portability and convenience. The same API can be implemented on different operating systems with different underlying system calls, so your program compiles and runs across platforms without you knowing each kernel's exact syscall numbers and conventions. The library also handles tedious details — packaging arguments, buffering, retrying interrupted calls, reporting errors in a uniform way. The honest nuance is that the boundary is not always tidy: identical-looking API functions can have subtly different behavior on different systems, and chasing a performance or correctness bug sometimes means looking past the API to the real system calls it makes (a tool that lists them, like a syscall tracer, is how you peek).
You call fread() to read a record. The library may have already pulled a big chunk into its own buffer with one read() system call, and now hands you bytes from that buffer with no kernel crossing at all. One API call, zero or one system call — they are not the same thing.
An API call and a system call are related but not identical; the library bridges them.
Beginners often say system call when they mean a library function. The API is what you write against and is portable; the system call is the kernel-crossing mechanism underneath and is OS-specific.