Why is PHP CLI considered as a kind of SAPI?

Question

According to Wikipedia's definition:

In other words, SAPI is actually an application programming interface (API) provided by the web server to help other developers in extending the web server capabilities.

Different kinds of SAPIs exist for various web-server extensions. For example, in addition to those listed above, other SAPIs for the PHP language include the Common Gateway Interface (CGI) and command-line interface (CLI).

But, i think when running a php file by terminal(command line), or using php-cli interactive shell only zend engine will be involved to interpret the code.

Is there something that I'm wrong about or don't know?

Can it be because of interacting with client through the web server?

---

Edit: Further explanations for a better understanding of the subject in addition to the accepted answer:

Advanced PHP Programming By George Schlossnagle

The outermost layer, where PHP interacts with other applications, is the Server Abstraction API (SAPI) layer. The SAPI layer partially handles the startup and shutdown of PHP inside an application, and it provides hooks for handling data such as cookies and POST data in an application-agnostic manner.

Below the SAPI layer lies the PHP engine itself. The core PHP code handles setting up the running environment (populating global variables and setting default .ini options), providing interfaces such as the stream's I/O interface, parsing of data, and most importantly, providing an interface for loading extensions (both statically compiled extensions and dynamically loaded extensions).

At the core of PHP lies the Zend Engine, which we have discussed in depth here. As you've seen, the Zend Engine fully handles the parsing and execution of scripts. The Zend Engine was also designed for extensibility and allows for entirely overriding its basic functionality (compilation, execution, and error handling), overriding selective portions of its behavior (overriding op_handlers in particular ops), and having functions called on registerable hooks (on every function call, on every opcode, and so on). These features allow for easy integration of caches, profilers, debuggers, and semantics-altering extensions.

The SAPI Layer

The SAPI layer is the abstraction layer that allows for easy embedding of PHP into other applications. Some SAPIs include the following:

• mod_php5 This is the PHP module for Apache, and it is a SAPI that embeds PHP into the Apache Web server.

• fastcgi This is an implementation of FastCGI that provides a scalable extension to the CGI standard. FastCGI is a persistent CGI daemon that can handle multiple requests. FastCGI is the preferred method of running PHP under IIS and shows performance almost as good as that of mod_php5.

• CLI This is the standalone interpreter for running PHP scripts from the command line, and it is a thin wrapper around a SAPI layer.

• embed This is a general-purpose SAPI that is designed to provide a C library interface for embedding a PHP interpreter in an arbitrary application.

The idea is that regardless of the application, PHP needs to communicate with an application in a number of common places, so the SAPI interface provides a hook for each of those places. When an application needs to start up PHP, for instance, it calls the startup hook. Conversely, when PHP wants to output information, it uses the provided ub_write hook, which the SAPI layer author has coded to use the correct output method for the application PHP is running in.

Read more

Answer 1

"Why" is always a slippery, somewhat philosophical, question; ultimately, the answer to "why is CLI considered a SAPI" is "because that's how the developers defined it". If they'd called it "CLI mode", would you still have asked "why"?

But you do ask a more concrete question, which can be paraphrased as:

When running a program on the CLI, why do you need a SAPI as well as the Zend Engine?

Or even more succinctly:

What does the CLI SAPI do?

The Zend Engine on its own takes a series of instructions, and executes them. It can manage variables, arithmetic, function definitions and calls, class definitions, and so on. But none of those are very useful if you can't get any output from the program; and most commonly you want to provide some variable input as well.

Some forms of input and output are based only on the operating system you're running on, not the SAPI - reading or writing a file based on an absolute path, or accessing something over a network connection. You could theoretically have a running mode that only gave access to those, but it would feel very limited. (Would that still be a "SAPI"? Definitely a philosophical question.)

Consider something as commonplace as echo: there's no absolute definition of "output" that the Zend Engine can manage directly. In a web server context, you expect echo to add some output to the HTTP response the server will send the client; in a command-line context, you expect it to show the output in the console where you ran the command, or be "piped" to another command if you run something like php foo.php | grep error.

The CLI SAPI doesn't provide all the same facilities that a web server SAPI would, but it fills a similar role in interfacing your program, running in the Zend Engine, to the outside world. Here are a few of the things it needs to do:

• Attach output to the parent console or "standard output" stream
• Make the "standard input" and "standard error" streams available
• Populate $argv and $argc based on the arguments the script was invoked with
• Populate $_ENV with the environment variables the process inherited
• Define an initial value for "current working directory" for use with relative file paths