Мысли о RESTful API

Я не буду писать о том, что RESTful ни на что не годится, и место его где-то в анналах истории, среди неудачных экспериментов. Но вот свое уверенное «Awesome!» по отношению к нему станет немного более сдержанным. Вообще, с моим отношением к категоричностям, меня очень и очень радует, что я обнаружил очередное бревно в своем глазу.

Без сомнения, сильной стороной REST является способность, в какой-то мере, эволюционировать в соответствии с изменяющимися требованиями, без серьезных изменений сервера. Выглядит все примерно так — у нас есть определенное количество иерархически и не очень выстроенных сущностей с которым мы можем различными способами взаимодействовать, клиент, со своей стороны, получает возможность делать бесконечно сложные вещи, которые вообще можно сделать с помощью объявленных сущностей.

К примеру, у нас есть метод, который по маршруту /users/:userId возвращает, скажем, такой объект:

{
  name: String,
  surname: String,
  nickame: String,
  friends: [{
    type: String,
    ref: 'User'
  }]
}

И вот, появилась у нас задача — кроме массива id друзей, покоящегося в поле friends, получать еще и их имена и ники — нет проблем! У нас же RESTful! Мы просто воспользуемся нашим известным маршрутом, и выполним запрос /users/:userId для каждого дружеского id. А позднее, разработчик API допишет новый метод для получения массива всех друзей друзей. Или не напишет — все ведь и так замечательно работает.

А графы? Мы ведь можем написать приложение которое будет рекурсивно запрашивать id друзей и строить граф связей. Право слово, это великолепно!

Серьезно. Представьте, смог бы я сделать что-то подобное, если бы у меня не было такого метода, а был бы какой-нибудь /init-app, возвращающий мне пользователя, его друзей и еще пару полезных штук, на основе информации, попавшей в сессию после авторизации? Думаю, это было бы не легко. Добавим толику хаоса — наша система будет эволюционировать, и вероятность того, что метод /init-app серьезно поменяется гораздо выше, чем у метода /users/:userId.

И вот я сижу и смотрю на iOS-приложение, которое, только во время открытия, шлет около двадцати запросов на мой замечательный RESTful-сервер. Сижу и думаю, не лучше ли сделать парочку комплексных методов, которые бы решали конкретные задачи, далекие от воздушных замков RESTful API? Что будет важнее в условиях сомнительного качества 3G: гибкость REST или гораздо меньшие транспортные расходы в комплексном API?

А может быть я просто не умею RESTful?

3.04.2014

Мысли о RESTful API

Похожие статьи: