GET /order/{id} — вернет 200, если заказ (ресурс) с таким id существует. 404, если заказ не найден, не корректный id или клиенту нельзя знать о существовании такого id
Полагаю что вы вообще не понимаете в чем суть проблемы отборажения бизнеслогики на статусы HTTP.
Первой много, а второго мало.
По шагам
404, если заказ не найден
Это ок.
404, если зне корректный id
Это не ок. Не пользователь должен догадаться из вашего "что-то пошло не так". А он должен получить внятную информацию. Особенно если это пользователь API.
404, если клиенту нельзя знать о существовании такого id
Это тоже не ок. Поскольку совершенно другая ситуация которая требует иной реакции.
Тут люди свой собственный пол сделали небинарным. А вы хотите завернуть всю широту возможных случаев в несколько десятков кодов…
Ваш код 404 не несет всей нужной информации. Т.е. нарушает сам REST по вашим же словам.
1) облачное управление, а не редактирование массы текстовых файлов
Ок, раз пошли такие пляски и перевод стрелок с подменой понятий.
То чем ваше решение лучше тех же crowdin, alconost?
2) авто-детект, где используются тексты — контекст
Это в каком месте автодетект?
Там где пишете @p?
3) предпросмотр/рендеры
Вот прямо пререндер моего любого мобильного приложения или апи? Это где такое?
4) авто-определение отсутствующих текстов, и многое другое.
Это все есть давно.
Ваш аргумент можно использовать и про Dropbox и Google Drive — зачем велосипед, когда есть стандартный простой FTP
Я пока свои аргументы не излагал. Но задал всего лишь вопрос.
Как SaaS вам нужно сравниваться с другими подобными сервисами (чего в статье вы не делаете).
А как инструментарий on-premise ну как бы все уже давно есть в стандартных вещах.
Руки наконец-то дошли сделать хоть что-то более вразумительное вашей попытки сравнивать размеры.
Симфония несомненно прошла большую эволюцию со времен 1/2/3 версии. Меня особенно порадовал приход Flex и ориентация на микроядро.
В этом контексте разница с микрофреймворками существенно сократилась.
Но вместе с тем общая унаследованная идеология все же осталась и не может быть быстро (а возможно и не планируется) изжита.
Задумался над тем как внятно объяснить свои ощущения и опыт — понял что это сложно.
Поэтому собрал вот такой вот наглядный пример, который отчасти демонстрирует разницу для меня.
Вот результат выполнения кода в рамках вами же предложенных скелетов приложений.
По моему опыту в mezzio код имеет тенденцию оставаться линейным по максимуму.
Хотя писать, естественно, можно по-разному.
P.S. Для симфонии пришлось прописать простой индекс-контроллер с банальным эхо.
Запускал все под встроенным в php сервером.
1) Плата только за использование, то есть стоимость равна интегралу под графиком используемых ресурсов — в случае же кубов, приходится платить за весь прямоугольник, причем высота прямоугольника — это точка пиковой нагрузки
Теоретические выкладки это хорошо, но практика говорит что все плохо. Достаточно посчитать конечные деньги. И тут serverless тупо проигрывает в большинстве типичных приложений.
Ваша "вскидка" очень далека от реальности.
Четыре года назад aws lambda была примерно в два раза дороже облачных решений от самого же амазона.
Разница облачных решений амазона к bare metal на единицу производительности была емнип х10
Дарю.
Режим markdown в десктопном варианте, где количество символов > вначале строки указывает вложенность цитаты
В мобильной версии работает также, уже без всяких дополнительных режимов
В ларе особый идиотизм с хранением реквеста в di-контейнере.
Полагаю что вы вообще не понимаете в чем суть проблемы отборажения бизнеслогики на статусы HTTP.
Первой много, а второго мало.
По шагам
Это ок.
Это не ок. Не пользователь должен догадаться из вашего "что-то пошло не так". А он должен получить внятную информацию. Особенно если это пользователь API.
Это тоже не ок. Поскольку совершенно другая ситуация которая требует иной реакции.
Тут люди свой собственный пол сделали небинарным. А вы хотите завернуть всю широту возможных случаев в несколько десятков кодов…
Ваш код 404 не несет всей нужной информации. Т.е. нарушает сам REST по вашим же словам.
Как исправлять будете?
Ок, раз пошли такие пляски и перевод стрелок с подменой понятий.
То чем ваше решение лучше тех же crowdin, alconost?
Это в каком месте автодетект?
Там где пишете @p?
Вот прямо пререндер моего любого мобильного приложения или апи? Это где такое?
Это все есть давно.
Я пока свои аргументы не излагал. Но задал всего лишь вопрос.
Как SaaS вам нужно сравниваться с другими подобными сервисами (чего в статье вы не делаете).
А как инструментарий on-premise ну как бы все уже давно есть в стандартных вещах.
GET /orderДля следующих случаев:
Можно на пальцах рассказать чем предложенный велосипед лучше стандартного простого gettext?
Тогда бы не было слов BigData, облака, Kafka…
Симфония несомненно прошла большую эволюцию со времен 1/2/3 версии. Меня особенно порадовал приход Flex и ориентация на микроядро.
В этом контексте разница с микрофреймворками существенно сократилась.
Но вместе с тем общая унаследованная идеология все же осталась и не может быть быстро (а возможно и не планируется) изжита.
Задумался над тем как внятно объяснить свои ощущения и опыт — понял что это сложно.
Поэтому собрал вот такой вот наглядный пример, который отчасти демонстрирует разницу для меня.
Вот результат выполнения кода в рамках вами же предложенных скелетов приложений.
По моему опыту в mezzio код имеет тенденцию оставаться линейным по максимуму.
Хотя писать, естественно, можно по-разному.
P.S. Для симфонии пришлось прописать простой индекс-контроллер с банальным эхо.
Запускал все под встроенным в php сервером.
Теоретические выкладки это хорошо, но практика говорит что все плохо. Достаточно посчитать конечные деньги. И тут serverless тупо проигрывает в большинстве типичных приложений.
Вы сильно лукавите (если не сказать врете) относительно оценки размеров «небольшого».
В большинстве случаев люди обходятся десятками подов. И вот зачем им в этом контексте кубик — я вообще не понимаю.
Пальцем в небо предположу что у вас очень несложное приложение.
Кубик и так-то выглядит оверкилом, если у вас нет хотя бы полутысячи подов.
А для той области где заходит serverless он вообще безумно громоздок.
Ваша "вскидка" очень далека от реальности.
Четыре года назад aws lambda была примерно в два раза дороже облачных решений от самого же амазона.
Разница облачных решений амазона к bare metal на единицу производительности была емнип х10
Я жил на Донбассе ровно до того момента как ко мне пришли «добровольцы с Кубани» спасать меня у холодильника от фашизма.
Гражданская ли эта война?
Впрочем, думать вы не обучены.
Я вам расскажу почему так происходит.
Основная масса тулчейнов писалась под линукс. И эти "упоротые" товарищи только декларируют портируемость, но не следуют ей.
Поэтому часто их (тулчейнов) использование под вин требует дополнительных танцев с бубнами.
Так что я в свое время, когда повзрослел и танцы надоели — для работы пересел на линукс. Он, конечно, говно по юзабилити, но мне нужно работу делать.
Как далеко вглубь веков копать будете в поисках владельцев территории?
Так не бывает.
Не хотеть платить за изменения — это да.
А чтобы быть не в силах — это нет.
Народ и составляет то самое государство.
Микрофреймворки — Slim, Mezzio
Фреймворки — Symfony, Laravel, Laminas
Ну свуле емнип есть пакеты и для того и для другого.
Я больше о компонентах симфонии любопытствовал
Slim, Mezzio?
Не надо опять.
Libreoffice лично меня возвращает в офис, каким он был на начало 90-х.
Это настолько уныло, что не надо.
И это при том, что работаю-то по линуксом. Вот просто в силу тупого вендорлока большинства тулчейнов.
Хотя wsl в этом контексте хорошее подспорье, но все ещё не идеальное.
P.S. По поводу headless
https://ewenorme.com/2016/06/14/automating-excel-for-headless-server-side-html-conversion/