SNP 2 enhances SNP 1 with a much easier request structure, dropping the need for awkward separator characters and introducing a more familiar URI-approach. Additionally SNP 2 provides extensibility in that the request structure follows the Win32 transport format, giving access to the full Snarl API.
An SNP 2 request begins with the header snp:// and is terminated by a single \r (aka CR, Chr(13), 0x0D…):
Each entry must contain a key and value; valueless keys are not permitted. Case is also important. Other than that, each SNP 2 request follows the standard Snarl API format.
A SNP 2 response is a single line of information separated by forward slashes:
SNP/<version>/<status code>/<status text>[/<data>]
Version is the latest version of SNP 2 supported by the Snarl instance that communications are taking place with. Communications with Snarl typically take place using an agreed protocol on an agreed port – there is currently no concept of a client being able to ‘version up’. A client can determine what version of SNP is available on a certain port by issuing the [version] command, which will return a version-specific SNP error message.
SNP2 does not support subscriptions or notification forwarding. Attempting to issue a [subscribe] request will result in an error – typically BadCommand, although this may vary depending on individual implementation.
SNP/HTTP is a variation of SNP 2 that can be used via a web browser. The syntax is the same, however the snp:// prefix is replaced with the traditional http:// prefix, as follows:
Note that while SNP/HTTP defaults to port 80, the port can usually be changed – again, this depends on individual implementation.
Unlike SNP 2.0, SNP/HTTP is not deprecated and development on it continues.