API V1.0
The L.A.S.S.I.E. API V 1.0 can be reached via
https://www.furcom.org/api/lassie/v1.0
Required POST Parameters
The parameters have to be send as URLencoded form data. The API needs at least two parameters to work:
- apikey
- request
- command (optional)
The API-Key has to be set in "System Settings". Preferrably a longer and unique key (like a MD5SUM).
| Requests and Commands | ||
|---|---|---|
| Request | Command | Description |
| lostandfounddb | lostandfound | (Default) Returns all active (not returned) lost & found items from the Lost & Found Database |
| lost | Returns all active (not returned) lost items from the Lost & Found Database | |
| found | Returns all active (not returned) found items from the Lost & Found Database | |
| returned | Returns all inactive / returned items from the Lost & Found Database | |
| briefings | Returns all briefings (i.e. Security News) classified as PUBLIC | |
The request "lostandfounddb" without a command will return the active Lost & Found Database entries for the respective Convention as a JSON. This includes Links to the uploaded images. Thus, the information can be processed on an external Website, e.g. the convention's homepage.
Example (CURL)
curl -X POST -d "apikey=ae629a834729fd3aac6d1f827b1793b0" -d "request=lostandfounddb" https://www.furcom.org/api/lassie/v1.0
This example will display the entire Lost & Found Database of FTC.
curl -X POST -d "apikey=ae629a834729fd3aac6d1f827b1793b0" -d "request=lostandfounddb" -d "command=lost" https://www.furcom.org/api/lassie/v1.0
This example will display only the lost items of the Lost & Found Database of FTC.
Output
The output of an valid request to the API will be a JSON-Object like the following examples:
Lost & Found Database
}
| Lost & Found fieldset | ||
|---|---|---|
| Key | Field | NULL |
| id | Numeric value, PRIMARY KEY | - |
| image | URL | null |
| title | Text | empty string |
| description | Text | empty string |
| status | L | F | R (Lost, Found or Returned) | - |
| lost_timestamp | ISO date | null |
| found_timestamp | ISO date | null |
| return_timestamp | ISO date | null |
Briefings Database
}
| Briefings fieldset | ||
|---|---|---|
| Key | Field | NULL |
| id | Numeric value, PRIMARY KEY | - |
| class | P (hopefully only P) | - |
| topic | Text | empty string |
| content | HTML | empty string |
| ops_id | Numeric value, the L.A.S.S.I.E. ID of the creator | - |
| datetime_creation | ISO date | - |
| datetime_lastchange | ISO date | null |
| datetime | ISO date which should be displayed. Is creation or lastchange whatever is bigger. | - |
Empty Object
{"data":[]}
Error Codes
The API will send a JSON-Object upon errors
{"error":{"code":"503","message":"Maintenance Mode enabled - please try again later"}}
The following error codes are implemented:
| Error Codes | ||
|---|---|---|
| Code | Message | Description |
| 401 | Unauthorized | API-Key is not correct or no API-Key provided. |
| 500 | Internal server error | Most likely the mySQL-Connection failed. A certain Dingo might be rather busy at this time. |
| 501 | Bad or no request | Whatever you send, it wasn't a valid request. |
| 503 | Maintenance Mode enabled - please try again later | Might follow an error 500 and the Dingo is still busy ... |