szurubooru/API.md

383 lines
8.2 KiB
Markdown
Raw Normal View History

2016-04-09 08:59:40 +02:00
`szurubooru` uses REST API for all operations.
2016-04-13 13:33:03 +02:00
# Table of contents
2016-04-09 08:59:40 +02:00
1. [General rules](#general-rules)
- [Authentication](#authentication)
- [Basic requests](#basic-requests)
- [File uploads](#file-uploads)
- [Error handling](#error-handling)
2. [API reference](#api-reference)
- [Listing users](#listing-users)
- [Creating user](#creating-user)
- [Updating user](#updating-user)
- [Getting user](#getting-user)
2016-04-09 09:21:56 +02:00
- [Removing user](#removing-user)
2016-04-09 08:59:40 +02:00
- [Password reset - step 1: mail request](#password-reset---step-2-confirmation)
- [Password reset - step 2: confirmation](#password-reset---step-2-confirmation)
3. [Resources](#resources)
- [User](#user)
4. [Search](#search)
2016-04-13 13:33:03 +02:00
# General rules
2016-04-09 08:59:40 +02:00
2016-04-13 13:33:03 +02:00
## Authentication
2016-04-09 08:59:40 +02:00
Authentication is achieved by means of [basic HTTP
auth](https://en.wikipedia.org/wiki/Basic_access_authentication). For this
reason, it is recommended to connect through HTTPS. There are no sessions, so
every privileged request must be authenticated. Available privileges depend on
the user's rank. The way how rank translates to privileges is defined in the
server's configuration.
It is recommended to add `?bump-login` GET parameter to the first request in a
client "session" (where the definition of a session is up to the client), so
that the user's last login time is kept up to date.
2016-04-13 13:33:03 +02:00
## Basic requests
2016-04-09 08:59:40 +02:00
Every request must use `Content-Type: application/json` and `Accept:
application/json`. An exception to this rule are requests that upload files.
2016-04-13 13:33:03 +02:00
## File uploads
2016-04-09 08:59:40 +02:00
Requests that upload files must use `multipart/form-data` encoding. JSON
metadata must then be included as field of name `metadata`, whereas files must
be included as separate fields with names specific to each request type.
2016-04-13 13:33:03 +02:00
## Error handling
2016-04-09 08:59:40 +02:00
All errors (except for unhandled fatal server errors) send relevant HTTP status
code together with JSON of following structure:
```json5
{
"title": "Generic title of error message, e.g. 'Not found'",
"description": "Detailed description of what went wrong, e.g. 'User `rr-` not found."
}
```
2016-04-13 13:33:03 +02:00
# API reference
2016-04-09 08:59:40 +02:00
Depending on the deployment, the URLs might be relative to some base path such
2016-04-13 13:33:03 +02:00
as `/api/`. Values denoted with diamond braces (`<like this>`) signify variable
2016-04-09 08:59:40 +02:00
data.
2016-04-13 13:33:03 +02:00
## Listing users
**Request**
`GET /users/?page=<page>&pageSize=<page-size>&query=<query>`
**Output**
2016-04-09 08:59:40 +02:00
```json5
{
"query": "rr-",
"users": [
<user>,
<user>,
<user>,
<user>,
<user>
],
"page": 1,
"pageSize": 5,
"total": 7
}
```
...where `<user>` is an [user resource](#user) and `query` contains standard
[search query](#search).
2016-04-13 13:33:03 +02:00
**Errors**
- privileges are too low
**Description**
2016-04-09 08:59:40 +02:00
Searches for users.
Available search named tokens:
| name | ranged? | array? |
| ----------------- | ------- | ------ |
| (anonymous) | | ✓ |
| `name` | | ✓ |
| `creation-date` | ✓ | ✓ |
| `creation-time` | ✓ | ✓ |
| `last-login-date` | ✓ | ✓ |
| `last-login-time` | ✓ | ✓ |
| `login-date` | ✓ | ✓ |
| `login-time` | ✓ | ✓ |
Anonymous search tokens are equivalent to `name` token.
Available search orders:
- `random`
- `name`
- `creation-date`
- `creation-time`
- `last-login-date`
- `last-login-time`
- `login-date`
- `login-time`
2016-04-13 13:33:03 +02:00
## Creating user
**Request**
`POST /users`
**Input**
2016-04-09 08:59:40 +02:00
```json5
{
"name": <user-name>,
"password": <user-password>,
"email": <email>
}
```
2016-04-13 13:33:03 +02:00
**Output**
2016-04-09 08:59:40 +02:00
```json5
{
"user": <user>
}
```
2016-04-13 13:33:03 +02:00
...where `<user>` is an [user resource](#user).
**Errors**
- such user already exists (names are case insensitive)
- either user name, password or email are invalid
- privileges are too low
**Description**
2016-04-09 08:59:40 +02:00
Creates a new user using specified parameters. Names and passwords must match
`user_name_regex` and `password_regex` from server's configuration,
respectively. Email address is optional. If the user happens to be the first
user ever created, they're granted highest available rank, becoming an
administrator. Subsequent users will be given the rank indicated by
`default_rank` in the server's configuration.
2016-04-13 13:33:03 +02:00
## Updating user
**Request**
`PUT /user/<name>`
**Input**
2016-04-09 08:59:40 +02:00
```json5
{
"name": <user-name>,
"password": <user-password>,
"email": <email>,
2016-04-09 21:41:10 +02:00
"rank": <rank>,
"avatarStyle": <avatar-style>
2016-04-09 08:59:40 +02:00
}
```
2016-04-13 13:33:03 +02:00
**Files**
- `avatar` - the content of the new avatar.
**Output**
2016-04-09 08:59:40 +02:00
```json5
{
"user": <user>
}
```
2016-04-13 13:33:03 +02:00
...where `<user>` is an [user resource](#user).
**Errors**
- the user does not exist
- the user with new name already exists (names are case insensitive)
- either user name, password, email or rank are invalid
- the user is trying to update their or someone else's rank to higher than
their own
- privileges are too low
- avatar is missing for manual avatar style
**Description**
2016-04-09 08:59:40 +02:00
Updates an existing user using specified parameters. Names and passwords must
match `user_name_regex` and `password_regex` from server's configuration,
respectively. All fields are optional - update concerns only provided fields.
2016-04-09 21:41:10 +02:00
To update last login time, see [authentication](#authentication). Avatar style
can be either `gravatar` or `manual`. `manual` avatar style requires client to
pass also `avatar` file - see [file uploads](#file-uploads) for details.
2016-04-09 08:59:40 +02:00
2016-04-13 13:33:03 +02:00
## Getting user
**Request**
`GET /user/<name>`
**Output**
2016-04-09 08:59:40 +02:00
```json5
{
"user": <user>
}
```
2016-04-13 13:33:03 +02:00
...where `<user>` is an [user resource](#user).
**Errors**
- the user does not exist
- privileges are too low
**Description**
2016-04-09 08:59:40 +02:00
Retrieves information about an existing user.
2016-04-13 13:33:03 +02:00
## Removing user
**Request**
`DELETE /user/<name>`
**Output**
2016-04-09 09:21:56 +02:00
```json5
{}
```
2016-04-13 13:33:03 +02:00
**Errors**
- the user does not exist
- privileges are too low
**Description**
2016-04-09 09:21:56 +02:00
Deletes existing user.
2016-04-13 13:33:03 +02:00
## Password reset - step 1: mail request
**Request**
`GET /password-reset/<email-or-name>`
**Output**
2016-04-09 08:59:40 +02:00
```
{}
2016-04-13 13:33:03 +02:00
```
**Errors**
- the user does not exist
- the user hasn't provided an email address
**Description**
2016-04-09 08:59:40 +02:00
Sends a confirmation email to given user. The email contains link containing a
token. The token cannot be guessed, thus using such link proves that the person
2016-04-13 13:33:03 +02:00
who requested to reset the password also owns the mailbox, which is a strong
2016-04-09 08:59:40 +02:00
indication they are the rightful owner of the account.
2016-04-13 13:33:03 +02:00
## Password reset - step 2: confirmation
**Request**
`POST /password-reset/<email-or-name>`
**Input**
2016-04-09 08:59:40 +02:00
```json5
{
"token": <token-from-email>
}
```
2016-04-13 13:33:03 +02:00
**Output**
2016-04-09 08:59:40 +02:00
```json5
{
"password": <new-password>
}
```
2016-04-13 13:33:03 +02:00
**Errors**
- the token is missing
- the token is invalid
- the user does not exist
**Description**
2016-04-09 08:59:40 +02:00
Generates a new password for given user. Password is sent as plain-text, so it
is recommended to connect through HTTPS.
2016-04-13 13:33:03 +02:00
# Resources
2016-04-09 08:59:40 +02:00
2016-04-13 13:33:03 +02:00
## User
2016-04-09 08:59:40 +02:00
```json5
{
"id": 2,
"name": "rr-",
"email": "rr-@sakuya.pl", // available only if the request is authenticated by the same user
"rank": "admin", // controlled by server's configuration
"rankName": "Administrator", // controlled by server's configuration
"lastLoginTime": "2016-04-08T20:20:16.570517",
"creationTime": "2016-03-28T13:37:01.755461",
"avatarStyle": "gravatar", // "gravatar" or "manual"
"avatarUrl": "http://gravatar.com/(...)"
}
```
2016-04-13 13:33:03 +02:00
# Search
2016-04-09 08:59:40 +02:00
Nomenclature:
- Tokens - search terms inside a query, separated by white space.
2016-04-13 13:33:03 +02:00
- Anonymous tokens - tokens of form `<value>`, used to filter the search
results.
- Named tokens - tokens of form `<key>:<value>`, used to filter the search
results.
- Special tokens - tokens of form `special:<value>`, used to filter the search
results.
- Order tokens - tokens of form `order:<value>`, used to sort the search
results.
2016-04-09 08:59:40 +02:00
Features:
2016-04-13 13:33:03 +02:00
- Most tokens can be negated like so: `-token`. Used with order tokens, it
flips the sort direction.
2016-04-09 08:59:40 +02:00
- Some tokens support multiple values like so: `3,4,5`.
- Some tokens support ranges like so: `100..`, `..200`, `100..200`.
- Date token values can contain following values: `today`, `yesterday`,
`<year>`, `<year>-<month>`, `<year>-<month>-<day>`.
2016-04-13 13:33:03 +02:00
- Order token values can be appended with `,asc` and `,desc` suffixes, which
control the sort direction.
2016-04-09 08:59:40 +02:00
Example how it works:
haruhi -kyon fav-count:3.. order:fav-count,desc -special:liked