Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Главное Свежее   Проекты

Dmitry

Подписаться Написать
22 дек 2014 в 16:00
Подробная информация
Комментарии
0
-- Понятные url адреса для пользователя
Речь же про API, когда это пользователи начали лезьть в потроха сервиса.

-- Сохранение состояния страницы через HTML5 History API (как бонус)
Опять же, очень косвенное отношение к REST API

-- Нет путаницы с дополнительной передачей параметров в запросах и обработкой их на сервере
Как раз и начинается путаница. Что передаем через GET параметры, что-то через POST в один и тот же обработчик.

-- Прозрачная логика клиентской части приложения
-- В случае надобности легко предоставить RESTful API для сторонних приложений
А другие протоколы не предоставляют этой возможности?

У REST есть много неопределенностей и из-за этого у каждого появляются свои реализации, которые они считают эталонными.

Нет более менее четкой спецификации. Например ответ о ошибке:
1. HTTP код
2. Всегда 200, информация об ошибке в ответе
3. 1 и 2 вариант

Формат ответа. Допустим вызываем метод получения пользователей:
1. [{ login: '' }]
2. { data: [{ login: '' }] }
3. { data: [ 'users': { login: '' }] }
Кто-как любит, так и делает. Большой минус если приходится интегрироваться с несколькими сервисами.

Веселье начинается, когда потребности выходят за рамки простого добавления, получения списка, удаления (типичный CRUD), т.е выходим за рамки /:collection/:id

Вот есть какая-либо сущьность, у который есть свойства и методы. Как эти действия выполнить?
1. POST /:collection/:id/on
2. Передавать "действие" в теле POST
3. Или вообще использовать, PUT, PATCH

Небольшая проблема возникает, когда идет кроссбраузерный запрос (CORS) к нашему API. На каждый url (/:collection/:id) будет слать предварительный OPTIONS запрос, дополнительные задержки.

Добавили GET/PATCH/DELETE обработчик /:collection/:id. И хотим в браузерном приложении использвать JSONP, чтобы избавиться от политик CORS. Придется добавлять еще один обработчик (3-в-1), для поддержки JSONP (он ведь только GET).

Нет стандратых инструментов для описания сервиса, по типу WSDL. Точнее более-менее широкоиспользуемых.

При типичном REST API, документация и параметры описываются вручную. Документация будет постоянно отставать.
3 Декабря 2014