Максим Мельник: нужно не в "разновидностях" MVC разбираться а в проблему, которую MVC и другие подходы решают. Ну то есть проблема у всех одна - разделение ответственности, преобразование представления данных из одного формата в другой, снижение связанности между приложением и презентационной логикой. И все становится чуть проще с осознанием что другие приложения тоже могут быть пользователями и для них тоже нужна презентационная логика (типичное заблуждение что в http api нет вьюшки).
А далее уже все проще... допустим в контексте WEB вам нужно сделать так, что бы ваше приложение ничего не знало о HTTP, формах, json-анх и т.д. а перед ним лежал какой-то адаптер который конвертирует http запросы в просто вызовы методов приложения и точно так же преобразует данные приложения в http ответы и т.д.
Будете вы это называть "контроллером", "мидлвэрами", "адаптерами" - это мелочи.
Станислав Макаров: Новая версия спецификации RAML дико радует теми фичами, коих мне не хватало в блупринтах.
OpenAPI это тот же сваггер. Чуть более многословная версия RAML зато больше вещей с ним работает. В силу того что для RAML еще не так много вещей из коробки с ним работающим, я сейчас пилю парсер + планирую конвертить пока либо в RAML 0.8 либо в OpenAPI.
1. Это не относится к вопросу. Как я уже говорил - это реализуется один раз для всех методов API.
2. Заглушка для всего проекта может и пилится за 1-2 дня максимум (хотя все сильно зависит от размера проекта, есть проекты где я апишку могу за 1-2 дня в принципе реализовать а не загрушку). Вот только аджайлы, итеративная разработка, проектируем ровно столько сколько нужно... ну то есть "всей заглушки" всеравно не будет и всеравно придется тратить кучу времени на "переделки". А так я даю кусочек API и работай нехочу. А если делать заглушки то меня будут слишком часто дергать.
3.1. Ну так откажитесь от github/gitlab, мы же "завязываемся" на них. Если внезапно apiary умрет (мало ли) то проект от этого не пострадает. Есть от них же в опенсурсе все по отдельности, просто через один сервис удобнее.
3.2. сторонние вэб сервисы мы не рассматриваем. Если они "сторонние" значит они уже есть и "мокать" их не нужно. А вот с реалтаймами, сокетами и т.д. - тут сложнее согласен. Тут так просто не выйдет, и для этого обычно пилятся заглушки. Благо это не такой большой процент задач.
3.3 не вижу противоречий. Мы лишь говорим о том, как декларировать этот слой. В моем варианте так же многие ошибки устраняются еще до тестирования. В вашем - так же. Ваш способ чуть более затратен для более простых проектов, мой не работает при сложных случаях коих меньшинство.
p.s. по поводу "категорически против" это я пожалуй погорячился. Скорее "мне не нравится но делаю так иногда". Вообще категоричного ничего не должно быть в вопросах подобного рода.
xmoonlight: ну и да, что бы "менее абстрактно" - берем apiary или любой подобный сервис и используем его для обявления слоя интеграции клиента и бэкэнда.
xmoonlight: описание "трубы" (сжатие, шифрование) это чуть другое, тут вы проектируете свой транспорт скорее нежели API. Его можно подменить на любой стадии разработки, оно никак не влияет на само API. Да и обычно все это уже реализовано на уровне фреймворков и операционной системы и разруливается абсолютно прозрачно для клиента.
И я категорически против, что бы мобильщики ждали пока бэкэндщик родит заглушку. Преимущество использования отдельных mock-серверов в том, что мобильщик может написать доку с частью API которая ему нужна прямо сейчас, скинуть бэкэндщику, и если тот заапрувит - просто начать работать не заставляя бэкэндщика "прерываться" на вашу задачу.
Дмитрий: повторюсь. Сначала nginx загружает ВЕСЬ файл в 1 гиг, и потом уже дает его PHP а тот грустит что может только 100 мегабайт. Во всяком случае это из вашего описания проблемы и я расписал почему так происходит.
Салават Ситдиков: для начала смотрите на access log, включите логирование медленных запросов..... А strace нужно задействовать когда примерно хотя бы понятно куда копать. Например если медленно работают вообще все запросы, может воркеры падают часто... такое бывает периодически.
слишком мало информации, сначала у вас нагрузка подскачила и вы сразу в strace полезли (смотреть системные вызовы). Непонятно, между этими штуками явно важный кусок информации пропущен.
