SNP 2.0 API
This is where I will be documenting the SNP 2.0 API
Check back here for updates...
Throughout this page, "SNP/HTTP" should be read as "SNP 2.0 over HTTP".
All communication takes place over TCP/IP using port 9887 (native) or port 80 (SNP/HTTP). The port used by Snarl to receive incoming SNP/HTTP requests can be changed from within the SNP/HTTP extension; the port used for native SNP cannot be changed.
Applications using SNP must register with Snarl before attempting to create notifications. The ability to create 'anonymous' notifications via earlier implementations of SNP has been deprecated and is not supported by SNP 2.0. An application may re-register itself at any time, in which case it will receive the same token it previously registered with. Once an application has registered successfully, it can add classes and create notifications.
Key Transport Differences
- Native SNP 2.0 allows for feedback responses, SNP/HTTP does not;
- Native SNP 2.0 is more efficient for continued communications;
The request structure is slightly different depending which transport medium is used, as follows:
Native SNP 2.0 packets must follow this basic template:
Some points to note:
- Each request must begin with snp://
- Each request must end with a single Carriage Return (0x0D)
- Each request must contain an action
The URL syntax for SNP/HTTP is very similar to that of native SNP 2.0:
Irrespective of the transport method used, the response format is always the same:
<version> The highest version of SNP Snarl supports. As of R2.4, this is always "2.0".
<status code> Identifies the response type. See the 'Status Codes' section.
<description> A human-readable version of the status code.
<data> Additional data provided. Not all requests return additional data, see the actions for more information.
These are the same for all variants, see the Generic API reference for details.