Разработка: что должно быть впереди фронтэнд или бекенд?

Т.е. фейковые данные отдаются бекендом пока он не будет готов, чтобы отдавать реальные?

unkwua: да и так же для бэкенда: пишется "заглушка"-клиент - генератор заранее заданных клиентских запросов на основе тест-кейса (с возможностью изменять эти запросы по желанию) и по ней отлаживается серверная часть.

xmoonlight: описание "трубы" (сжатие, шифрование) это чуть другое, тут вы проектируете свой транспорт скорее нежели API. Его можно подменить на любой стадии разработки, оно никак не влияет на само API. Да и обычно все это уже реализовано на уровне фреймворков и операционной системы и разруливается абсолютно прозрачно для клиента.

И я категорически против, что бы мобильщики ждали пока бэкэндщик родит заглушку. Преимущество использования отдельных mock-серверов в том, что мобильщик может написать доку с частью API которая ему нужна прямо сейчас, скинуть бэкэндщику, и если тот заапрувит - просто начать работать не заставляя бэкэндщика "прерываться" на вашу задачу.

xmoonlight: ну и да, что бы "менее абстрактно" - берем apiary или любой подобный сервис и используем его для обявления слоя интеграции клиента и бэкэнда.

Сергей Протько:
1. про "трубу": я создаю инструмент контроля взаимодействия клиента и сервера. Почему так? потому, что при шифрации/дешифрации данных, они могут быть некорректными на противоположной стороне.

2. "И я категорически против, что бы мобильщики ждали пока бэкэндщик родит заглушку. " - Ну так заглушка (сам скелет) разрабатывается 1-2 дня - максимум. Далее - просто таблица готовности функций идёт => никому не придётся ждать.

3. "берем apiary или любой подобный сервис и используем его для обявления слоя интеграции клиента и бэкэнда" - а вот тут, уже я категорически против, т.к.:
3.1 весь процесс разработки не должен быть завязан на сторонние интернет-сервисы и эта работа должна быть выполнена именно в рамках проекта.
3.2 это может сильно отличаться от того, что могут предложить сторонние веб-сервисы, например, потоковые сокеты с изменением данных во времени.
3.3 Как бонус - этот слой избавляет от большинства ошибок на этапе тестирования.

xmoonlight:

1. Это не относится к вопросу. Как я уже говорил - это реализуется один раз для всех методов API.

2. Заглушка для всего проекта может и пилится за 1-2 дня максимум (хотя все сильно зависит от размера проекта, есть проекты где я апишку могу за 1-2 дня в принципе реализовать а не загрушку). Вот только аджайлы, итеративная разработка, проектируем ровно столько сколько нужно... ну то есть "всей заглушки" всеравно не будет и всеравно придется тратить кучу времени на "переделки". А так я даю кусочек API и работай нехочу. А если делать заглушки то меня будут слишком часто дергать.

3.1. Ну так откажитесь от github/gitlab, мы же "завязываемся" на них. Если внезапно apiary умрет (мало ли) то проект от этого не пострадает. Есть от них же в опенсурсе все по отдельности, просто через один сервис удобнее.

3.2. сторонние вэб сервисы мы не рассматриваем. Если они "сторонние" значит они уже есть и "мокать" их не нужно. А вот с реалтаймами, сокетами и т.д. - тут сложнее согласен. Тут так просто не выйдет, и для этого обычно пилятся заглушки. Благо это не такой большой процент задач.

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

p.s. по поводу "категорически против" это я пожалуй погорячился. Скорее "мне не нравится но делаю так иногда". Вообще категоричного ничего не должно быть в вопросах подобного рода.

Сергей Протько: "Это не относится к вопросу. Как я уже говорил - это реализуется один раз для всех методов API." - согласен, что один раз для всех методов API, поэтому оно и стоит в заглушке, таким образом, я проверяю сразу и корректность алгоритма шифрования, и корректность обмена данными.
С остальным - полностью согласен!