Формально это означает что тип ответа зависит от устройства в частном случае, а в конкретном - от типа запроса. Но даже теория RESTful не дает ответа - там запросы GET POST PUT DELETE и еще там какой-то, ни один из них не говорит о типе желаемого ответа - json, jsonp, html, string, serialized, xml, csv, file?
Пишут что-то про заголовки HTTP_ACCEPT, осталось осознать что пользователь их задавать не будет и придется сначала их задать, а потом еще в модели поехать крышей.
Наверное самый коротко-кодовый способ это в роутер запихнуть параметр "accept", и задавать его приложением автоматически, а в коде моделей сократить до $this->res->status(403)->error(code, msg); Есть возможность переопределить тип вывода добавив ->json() но это нужно выпилить чтобы не делать каждый раз
Григорий Васильков: пользователю и не нужно его задавать. например, браузер автоматом ставит html в accept.
a программисту ясен пень его нужно указывать явно, если он хочет получить данные в другом формате, а не html. ибо только он знает, какой формат он хочет получить.
ну и в ресте для указания формата обычно используется заголовок content-type.
тогда хорошо, с одной стороны браузер хочет получить какой-то контент, с другой стороны я хочу отдать какой-то контент - результат получится смешанный из этих двух, если запускается html controller то и возврат должен быть страницы ошибки
Григорий Васильков: кагбе логично, что если клиент просит хтмл, то и отдавать хтмл, а если просит джейсон, то отдавать джейсон, и т.д.
проблема то в чем?
в том что я не уверен, что фреймворк знает чего хочет клиент. и тем более не уверен, что клиент сам знает чего он хочет, и в том, что клиент как тут любят бросаться словечко "миддлеваре" поставил в запросе тип желаемого ответа, и вообще что для современного уникального программиста вообще существует какое-то понятие "подумай о других", есть кажется только "моя непохожая душа!"
Григорий Васильков: > я не уверен, что фреймворк знает чего хочет клиент
так прочти документацию по фреймворку.
есть фреймворки, которые делают анализ заголовков и автоматически возвращают данные в нужном формате, есть фреймворки, которые эту заботу отдают на откуп програмисту.
> не уверен, что клиент сам знает чего он хочет
так не бывает.
если клиент не указал явно, что он ждет данные в определенном формате, то отдается дефолтный хтмл.
Дев, я как раз и пишу микрофреймворк и проблема в том что должен разобраться как это работает, чтобы предусмотреть оба случая - дать свободу программисту и если программист мудак - выполнить все что смогу без него. и только потом думать про ошибку
проще говоря на запрос определенного урла разумнее ли делать определенный ответ, /ajax/action => json || /action => html потому что "свобода программиста" как бы автоматически означает что он шарит. а шарит понятие растяжимое, оно где-то в сравнении между "слишком просто" и "слишком сложно"
Григорий Васильков: >по спецификации разве хтмл по дефолту?
нет мифических строгих правил, высеченных в граните. есть собственная практика/опыт и здравый смысл.
есть смысл в данном конкретном случае отдавать по дефолту не html, a что-то другое? вперед, никто не мешает/не сдерживает/не запрещает. ибо универсальных правил/рецептов не существует.
> на запрос определенного урла разумнее ли делать определенный ответ
не разумнее:
1. плодятся сущности/точки входа/дублирование кода
2. как при таком подходе по запросу на /ajax/action определить клиент хочет json или xml или jsonp или еще что-то? плодить еще урлы типа /ajax/json/action или /ajax/action.json и т.п.?
Комплект бумаги который говорит что нужно делать так, вот почему, и контакты авторов. Кажется, у нас такого документа нету, потому что мы в интернете и кто-то сказал как делать, а потом сьебался за монитор и ни за что не отвечает, и на звонки тоже не отвечает и вообще вон он даже службу поддержки написал которая убедит вас в том что вы верблюд, ну я про коня в вакууме
Про "не разумнее", теперь ясно... контроллерам разумно обрабатывать разные типы запросов и просто выбирать разные действия, чем плодить новые контроллеры, а истина где-то посередине между "полотно кода" и "куча файлов".
Григорий Васильков: так нет такого.
рестфул - это подход/принцип/стиль, который каждый подгоняет под себя как считает нужным, но отнюдь не стандарт.
тут до сих пор нет единного мнения и не могут определиться каким методом наиболее православно производить определенные действия (например, для изменений использовать put или post или patch), а ты о такой ерунде как "что же возвращать по дефолту". да что хочешь, то и возвращай. стандартов по данному вопросу нет.
В любом случае ты мне многое прояснил, большое тебе спасибо.
Где-то я уже слышал про подход/принцип/стиль.... методология??? БЭМ?
Мы придумали так и сказали что это круто, но у нас было много денег и поэтому вы нам поверили. А теперь пришла пора купить apple macbook pro, и понять что ваших 8 гигов не будет хватать даже для игрушек, а драного смартфона хватило бы чтобы управлять космической станцией.
Но как мне сегодня сказал один чувак "Гриха, ты не прав, ты живешь пытаясь изменить мир, тебе нужно притворится водой и помочь ему самому себя уничтожить. Так будет легче, тебя будут любить, денег будет, а то что ты пытаешься разобраться во всем - это ты зря", и все понимают, и надеются что их не коснется :))
Григорий Васильков: ну все так и происходит. кто-то что-то придумал и пустил это в массы. не пошло? умерло. пошло? отлично, пользуемся. офигенно пошло? собираемся в кучку и стандартизируем.
так происходит не только в it, но и в совершенно других областях.
что касается подход/принцип/стиль.... методология/фреймворк/etc то их прелесть как раз в том, что они не являются стандартами, от которых невозможно отойти.
нравится и видишь профит? учишь и пользуешь.
не нравится? не пользуешь и забыл.
бодаться с этим не имеет никакого смысла.
Единственная херня которая меня не отпускает - что достаточно сложные технологии превращаются в компанию, которая начинает нанимать людей, давая им огромные финансы, на знание собственных технологий. И волей неволей получается бодание - с фигали у них такие зарплаты, а мы делаем то же самое - но вместо 200 штук получаем 20 штук.
И хочется сказать - это наш выбор, сколько получать - если хотим 20, получаем 20. Как будто на уровне фреймворка происходит отбор - чем он сложнее и умнее, тем более профессиональные люди способны хоть как-то сдвинуть его с места, тем более профессиональные люди нанимаются, тем больше им платят, но казалось бы с фига ли, делают то они вроде одно и то же, как и все.
Правда блещут знаниями в области "разработки приложений на высоких нагрузках" - тут вообще отдельная тема. Перед устройством на работу тебя спрашивают "делал ли ты высокие нагрузки" - ты говоришь - "нет" - они тебя не берут. Говоришь "да" - начинают задавать чисто собственные вопросы по высоким нагрузкам, а гарантию что у вас понятия совпадают - ну ее нет, они о своем, ты о своем, вот такая лотерея получается - там где зарплата выше помимо того что учил какую-то херь всю жизнь, так после этого еще и кубик на параметр удачи надо кинуть строго 4 из 6, тогда можно смело хвастаться что middleware-девелопер, а не просто веб-кодер.
И хрен бы с ним, это же проблемы той компании, куда они берут спеца, побеждает красноречие короче, опыт и умение _просто_ излагать мысли на птичках выдают дилетанта почему-то.
Прикол начинается потом, когда маленькие компании начинают копировать с больших (у нас как раз маленькая). Руководство тратило тратило бабло на разные разработки - а люди _не_покупают_. И оно сделало вывод что эксперименты - это плохо, нужно копировать у других. И тут понеслось - а в гугле вот так делают, а в яндексе вот так, а давайте изучим такой-то стек, и ты сидишь и думаешь нахер я тут работаю?
Потому что 20-ку платят, лучшую зарплату в городе.
под "маленькой" скрывается 400 человек по всей Республике на торговых сервисных центрах.
===
В практике выглядит примерно так: "Руководство выбрало Битрикс! Потому что это система у которой есть комьюнити, она зарекомендовала себе в 1С Торговля и Бухгалтерия, и у них есть техническая поддержка, кроме того она платная и у нее хорошая админка". И ты такой "А чо у нас не спросили?" - они такие "Так кто ж с программистами общается, с вами ни о чем говорить невозможно, мы должны быть современными, понимаете?"
Ну вообще верно... всегда ведь два взгляда на вещи - первый - люди тупят, второй - машину плохо собрали, раз люди тупят, а она не работает... сказать директору что не прав - чревато фразой "ты знаешь как правильно? иди создай свое" потому как его опыт в организации куда выше... через подмену понятий все доказывается.
Простой
