History[edit]
NSAPI was initially developed by Rob McCool at Netscape for use in Netscape Enterprise Server. A variant of NSAPI can also be used with Netscape Directory Server.
Because there is no formal standard, applications that use NSAPI are not necessarily portable across server software. As of 2007, varying degrees of support for NSAPI are found in Sun Java System Web Server and Zeus Web Server.
NSAPI plug-ins[edit]
Applications that use NSAPI are referred to as NSAPI plug-ins. Each plug-in implements one or more Server Application Functions (SAFs).
To use a SAF, an administrator must first configure the server to load the plug-in that implements that SAF. This is typically controlled by a configuration file named magnus.conf. Once the plug-in is loaded, the administrator can configure when the server should invoke the SAF and what parameters it should be passed. This is typically controlled by a configuration file named obj.conf.
[edit]
NSAPI can be compared to an earlier protocol named Common Gateway Interface (CGI). Like CGI, NSAPI provides a means of interfacing application software with a web server. Unlike CGI programs, NSAPI plug-ins run inside the server process. Because CGI programs run outside of the server process, CGI programs are generally slower than NSAPI plug-ins. However, running outside of the server process can improve server reliability by isolating potentially buggy applications from the server software and from each other.
In contrast to CGI programs, NSAPI SAFs can be configured to run at different stages of request processing. For example, while processing a single HTTP request, different NSAPI SAFs can be used to authenticate and authorize the remote user, map the requested URI to a local file system path, generate the web page, and log the request.
After Netscape introduced NSAPI, Microsoft developed ISAPI and the Apache Software Foundation developed Apache API (or ASAPI: Apache Server API). All three APIs have a number of similarities. For example: NSAPI, ISAPI and Apache API allow applications to run inside the server process. Further, all three allow applications to participate in the different stages of request processing. For example, Apache API hooks closely resemble those used in NSAPI.[1]