RESTful API может создаваться не только для сторонних сервисов. Он может использоваться одностраничными приложениями для работы с бэк-эндом. Вот несколько основных моментов, которые нужно знать при проектировании интерфейса.
URLs и действия
Ключевым принципом REST является деление вашего API на логические ресурсы. Управление этими ресурсами происходит с помощью HTTP-запросов с соответствующим методом — GET, POST, PUT, PATCH, DELETE.
Ресурс должен описываться существительным во множественном числе. Действия над ресурсами, обычно, определяются стратегией CRUD и соответствуют HTTP-методам следующим образом:
-
GET /api/users
— получить список пользователей; GET /api/users/123
— получить указанного пользователя;POST /api/users
— создать нового пользователя;PUT /api/users/123
— обновить все данные указанного пользователя;PATCH /api/users/123
— частично обновить данные пользователя;DELETE /api/users/123
— удалить пользователя.
Если ресурс существует только в контексте другого ресурса, то URL может быть составным:
GET /api/posts/9/comments
— получить список комментариев к записи №9;GET /api/posts/9/comments/3
— получить комментарий №3 к записи №9.
Когда действие над объектом не соответствует CRUD операции, то его можно рассматривать как составной ресурс:
POST /api/posts/9/like
— отметить запись №9 как понравившуюся;DELETE /api/posts/9/like
— снять отметку «понравилось» с записи №9.
Действия по созданию и обновлению ресурсов должны возвращать ресурс
Методы POST, PUT или PATCH могут изменять поля ресурса, которые не были включены в запрос (например, ID, дата создания или дата обновления). Чтобы не вынуждать пользователя API выполнять ещё один запрос на получение обновлённых данных, такие методы должны вернуть их в ответе.
Фильтры, сортировка и поиск
Любые параметры в HTTP-запросе могут быть использованы для уточнения запроса или сортировки данных.
GET /api/users?state=active
— список активных пользователей;GET /api/tasks?state=open&sort=priority,-created_at
— список невыполненных задач, отсортированных по приоритету и дате создания (сперва новые задачи).
Постраничная навигация
Когда нужно в ответ на запрос списка объектов добавить информацию о постраничной навигации, стоит воспользоваться HTTP-заголовком Link, а не добавлять обёртки данным.
Пример заголовка:
Link: <http://domain.tld/api/users?page=5&per_page=100>; rel="next",
<http://domain.tld/api/users?page=3&per_page=100>; rel="prev",
<http://domain.tld/api/users?page=1&per_page=100>; rel="first",
<http://domain.tld/api/users?page=10&per_page=100>; rel="last"
Возможные значения rel
:
next
— следующая страница результатов;prev
— предыдущая страница результатов;first
— первая страница результатов;last
— последняя страница результатов.
Важно следовать этим значениям, а не конструировать собственные URL-ы потому, что иногда постраничная навигация может основываться на сложных правилах, а не простом переборе страниц.
Переопределение HTTP-метода
Для совместимости с некоторыми серверами или клиентами, которые не поддерживают другие HTTP-методы кроме GET и POST, может быть полезным их эмуляция. Значение метода передаётся в заголовке X-HTTP-Method-Override
, а сам он выполняется как POST-метод. GET-запросы не должны менять состояние сервера!
Коды HTTP-статуса
200 OK
— ответ на успешный запрос GET, PUT, PATCH или DELETE.201 Created
— ответ на POST запрос, в результате которого произошло создание нового объекта. Ответ так же должен сопровождаться заголовкомLocation
, указывающий на URL ресурса.204 No Content
— ответ на успешно выполненный запрос, который ничего не возвращает (например, DELETE).404 Not Found
— запрашиваемый объект не найден.500 Internal Server Error
— ошибка на сервере.
В случае ошибок, в ответе может содержаться отладочная информация для разработчиков, если это возможно.
Метаданные
Любые данные, которые лишь опосредованно относятся к результату запроса, но могут быть полезны клиенту, стоит отдавать в виде HTTP-заголовков. Создание обёрток над данными ломает совместимость с принципами REST.