Здравствуйте, Ziaw, Вы писали:

Z>Ничего особо страшного скаффолдинг не создаст.
Субъективно. Объективный критерий: лишние сущности не нужны.

Z>В этом месте стоит понять, что подразумевается под серьезным приложением. Бизнес веб-приложения, как правило, содержат crud в товарных количествах. Можешь привести пример, задачи где непонятно, будет crud или нет?
Вопрос должен быть не "будет ли crud?", a "какой он будет и сколько?".
Нужен богатый клиент и простые rest-сервисы? RoR отказать.
Обычная бизнес-система для HR? Можно.

Здравствуйте, novitk, Вы писали:

N>Субъективно. Объективный критерий: лишние сущности не нужны.

Какие сущности в скаффолдинге лишние? Views? На их удаление тратится 10 секунд (возможно даже есть опция чтобы их не генерить, мне проще удалять, чем запоминать ее).

N>Вопрос должен быть не "будет ли crud?", a "какой он будет и сколько?".

Так или иначе он будет, в некоторых случаях без D.

N>Нужен богатый клиент и простые rest-сервисы? RoR отказать.

После удаления views от скаффолдинга остаются именно простые rest-сервисы. Отказать, потому, что хорошо умеет простые rest-сервисы?

Для богатого клиента RoR может помочь простой интеграцией webpack в приложение. Можно конечно разделить бэкенд и фронтэнд, но какой в этом смысл? Не проще ли все делать в одном проекте и одной IDE?

N>Обычная бизнес-система для HR? Можно.

Насколько я вижу задачу, CRUD там присутствует в больших количествах. Основные сущности — Employee, Department, что-то их связующее и возможно Order. Чистый CRUD на все эти сущности и море мелких сопутствующих.

Здравствуйте, Ziaw, Вы писали:

Z>Какие сущности в скаффолдинге лишние? Views? На их удаление тратится 10 секунд (возможно даже есть опция чтобы их не генерить, мне проще удалять, чем запоминать ее).
Там процентов 90% для мок-сервиса будет лишними. Минимальный пример должен выглядит как-то так:

from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
    return "Hello World!"

N>>Нужен богатый клиент и простые rest-сервисы? RoR отказать.
Z>После удаления views от скаффолдинга остаются именно простые rest-сервисы. Отказать, потому, что хорошо умеет простые rest-сервисы?
Даже если забыть про views, rest-сервисы там останутся фиговые, так как ничего интересней скаффолдингом на ORM не сделать.

Z>Для богатого клиента RoR может помочь простой интеграцией webpack в приложение. Можно конечно разделить бэкенд и фронтэнд, но какой в этом смысл? Не проще ли все делать в одном проекте и одной IDE?
Проще, только в RoR качество будет на троечку. Xочется качества, нет желание возиться с react.js/angular и все в одном проекте? Вам сюда https://plot.ly/products/dash/. Результат будет быстрее и лучше чем с Django/RoR.

N>>Обычная бизнес-система для HR? Можно.
Z>Насколько я вижу задачу, CRUD там присутствует в больших количествах. Основные сущности — Employee, Department, что-то их связующее и возможно Order. Чистый CRUD на все эти сущности и море мелких сопутствующих.
Совершенно верно, при этом еще и денег не дадут. Поэтому RоR для подобных "опердней" вполне себе решение.

Здравствуйте, Ziaw, Вы писали:

Z>Python — отличный язык с кучей библиотек, но веб-фреймворки у него заметно хуже рельс. Типовых решений либо мало либо их сложно кастомизировать.

Я могу где-то согласиться с другими утверждениями, но вот ^ — чистый bs. В питоне сейчас есть штук пять фреймворков(tornado, flask, bottle, cherrypy, dash), которые намного лучше рельсо-подобного Django. Ты очевидно их даже не смотрел.

Здравствуйте, novitk, Вы писали:

N>Я могу где-то согласиться с другими утверждениями, но вот ^ — чистый bs. В питоне сейчас есть штук пять фреймворков(tornado, flask, bottle, cherrypy, dash), которые намного лучше рельсо-подобного Django.

С какой стороны django является рельсоподобным? По мне так это очень узконаправленный инструмент и на RoR не похож от слова совсем.

N>Ты очевидно их даже не смотрел.

Я ими не пользовался, но мельком смотрел. Это аналоги рубийной sinatra (и то она побогаче будет). Дают слабенький роутер с простеньким view engine (в лучшем случае заменяемым) и крутись как хочешь. В тех приложениях, что я делаю, мне бы потребовалось, кроме разработки функционала, заниматься допиливанием множества утилитарных вещей, а потом их все время поддерживать. Зачем?

Здравствуйте, novitk, Вы писали:

N>Здравствуйте, Ziaw, Вы писали:

Z>>Какие сущности в скаффолдинге лишние? Views? На их удаление тратится 10 секунд (возможно даже есть опция чтобы их не генерить, мне проще удалять, чем запоминать ее).
N>Там процентов 90% для мок-сервиса будет лишними. Минимальный пример должен выглядит как-то так:
N>

N>from flask import Flask
N>app = Flask(__name__)
N>@app.route("/")
N>def hello():
N>    return "Hello World!"
N>

Я как-то пропустил момент, когда мы перешли с обсуждения разработки приложений на разработку мок-сервисов. Код на рельсах этого мока будет примерно такой:

# flask_controller.rb
class FlaskController < ApplicationController
  def hello 
    render content: 'Hello World!'
  end
end

# routes.rb
get '/:action', controller: 'FlaskController'

Хочешь сказать, что этот код чем-то заметно отличается в стоимости разработки и поддержки?


N>Даже если забыть про views, rest-сервисы там останутся фиговые, так как ничего интересней скаффолдингом на ORM не сделать.

Нельзя ли пример? Типа вот в этом случае на рельсах получается фигово, а на питоне я быстрее и лучше сделаю так.

N>Проще, только в RoR качество будет на троечку. Xочется качества, нет желание возиться с react.js/angular и все в одном проекте? Вам сюда https://plot.ly/products/dash/. Результат будет быстрее и лучше чем с Django/RoR.

Ты не понял, я не отказываюсь возиться с рич клиентом. Я говорю про то, что в RoR этот рич клиент (react.js/angular) разрабатывается в одном проекте с бэкэндом. Все прекрасно разрабатывается и деплоится одновременно (и моки писать не нужно). Это удобно.

N>Совершенно верно, при этом еще и денег не дадут. Поэтому RоR для подобных "опердней" вполне себе решение.

Ты так неудачно слился что ли? По теме есть что сказать? Подошло бы что-то типа "CRUD там не будет", "там будут совсем другие сущности, которые не ложатся в REST модель (которая как раз про CRUD)". Хорошо бы с примерами.

Здравствуйте, Ziaw, Вы писали:

Z>Я ими не пользовался, но мельком смотрел. Это аналоги рубийной sinatra (и то она побогаче будет). Дают слабенький роутер с простеньким view engine (в лучшем случае заменяемым) и крутись как хочешь. В тех приложениях, что я делаю, мне бы потребовалось, кроме разработки функционала, заниматься допиливанием множества утилитарных вещей, а потом их все время поддерживать. Зачем?

Вот и расскажи про веб функционал в RoR, которого нигде нет. Мне реально интересно. Что он такого может, что не может например Tornado из коробки? Для справки Tornado может C10k+, а RoR нет.

Здравствуйте, Ziaw, Вы писали:

Z>В этом месте стоит понять, что подразумевается под серьезным приложением. Бизнес веб-приложения, как правило, содержат crud в товарных количествах. Можешь привести пример, задачи где непонятно, будет crud или нет?
Как правило, "бизнес веб-приложения" содержат в товарных количествах CRUD не от хорошей жизни. А в основном, из-за того, что развитие приложения застревает на уровне ER-модели, а на анализ сценариев ресурсов уже не остаётся.
В итоге пользователь остаётся наедине с 200 "справочниками", которые надо забивать руками в нужном порядке, чтобы выполнить простейшую бизнес-транзакцию.
А хотелось ему вовсе не этого, потому что такая работа — это мука. Посмотрите на любое современное клиенто-ориентированное приложение. В основном рекомендую мобильные приложения, т.к. именно там сейчас идёт основная активность, и там применяются передовые UX-концепции. Яндекс-такси — где там Crud? Один уголочек: "история поездок". Какой-нибудь Альфа-Банк посмотрите: вот уж самая что ни на есть традиционная область, brick and mortar.
Нет там никакого Crud. Транзакции типа "открыть депозит", "открыть счёт", "купить облигации ПиФ" — это работа с десятками внутренних табличек. Ничего этого в UI и в помине нету. И не надо — потому что пользователю всё равно, что рублёвые депозиты — это один модуль, а валютные — совсем другой. Что оплата с дебетового счёта — это один вид транзакции, а с кредитной карты — совсем другой. Это всё ненужные подробности.

И REST интерфейс никакого отношения к CRUD не имеет. Ну, в том смысле, что он совершенно точно не выставляет наружу структуру табличек БД, что провоцируют делать все убогие CRUD-фреймворки.
Он выставляет наружу состояние синтетических ресурсов; они могут ложиться на RDBMS произвольно сложным образом. Хороший фреймворк для этого должен давать мне лёгкие возможности по вот этому отображению туда-сюда. Чтобы PATCH на атрибуты Status и Comment инициировали асинхронную операцию, а не превращался в UPDATE Orders where Id = {0}.

Здравствуйте, novitk, Вы писали:

N>Вот и расскажи про веб функционал в RoR, которого нигде нет. Мне реально интересно. Что он такого может, что не может например Tornado из коробки? Для справки Tornado может C10k+, а RoR нет.

К тебе, как к знатоку вопрос — в торнадо нормально работает hot reload? Можно запустить приложение и потом сутки его дорабатывать, обновляя результат в браузере меньше чем за секунду после внесения изменений в код (бэкенд, фронтэнд, js, стили)?

Сразу оговорюсь, я плохо знаю торнадо для точного ответа на вопрос, могу что-то лишнего написать.

На вскидку по фичам рельс по сравнению с торнадо — CSRF protection, гораздо более декларативный restful роутинг (в отличии от плохо поддерживаемого, начиная с некоторого объема, набора хендлеров), поддержка форматов (легко давать ответы в нужном формате по Accept (html/json/js/pdf/xls)), простое управление кешированием (как ответов http, так и фрагментов ответа), удобная фильтрация параметров запроса и вообще работа с ними, encrypted session storage, signed cookies, Content Security Policy, WebSockets (могу ошибаться, в торнадо либо нет либо есть в очень зачаточном состоянии), простой file uploads, form helpers, локализация.

Управление ассетами (несколько видом компиляции css/js: как собственная система сборки, так и хорошо интегрирующийся webpack), продуманная система view/layout (я работал с несколькими, везде чувствовал проблемы, сделать то же самое можно, но либо дублируем код либо вообще творим какие-то извращения).

То, что вроде не web, но почти всегда нужно — mailers (отправка почты), active jobs (фоновые задачи), active storage (хранение файлов в различных удаленных хранилищах).

То, что не рельсы, а гемы для них, но используется всегда и почти наверняка не имеет аналогов для Торнадо:

Devise — система пользователей с кучей настроек для разных протоколов, регистрация, вспомнить пароль, защита от подбора, oauth.
Cancan — система прав пользователей, декларативное описание и проверка прав на сущности и операции в системе.

Я в свое время изобретал эти велосипеды для других платформ и примерно знаю, сколько это стоит и насколько легко переносится потом в другой проект.

Основной плюс озвучу несколько холиварно — рельсы (если хорошо их знать) почти всегда дают возможность решать задачу бизнеса, а не ковыряться в технологиях.

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

Здравствуйте, Sinclair, Вы писали:

S>Отож. К сожалению, я не могу диктовать сторонним производителям, как именно им писать свой код. Поэтому мне важно быстро обнаружить проблему. Санитизация потенциально косячной информации должна делаться максимально быстро и локально — чтобы я сразу видел "от сервера пришёл какой-то мусор", а не "ой, я пытаюсь получить .length() от null", который вылетает хрен знает где в стеке. Как у нас с этим в динамике типа руби? Или у меня .length() от null волшебно даст тоже null, и проблема будет обнаружена только в интеграционном тесте?

Насколько я понял, статика в данном случае тоже особо не помогла. В динамике это ловится валидацией, которая по коду ничуть не сложнее описания типа, но гораздо мощнее.

S>Ну вот вы рассказываете про плохую статику, образца 1990х. В хорошей статике к форме1 биндится не Person, а from p in Person select FirstName, LastName, Age, NickName, Avatar. Безо всяких if, lazy load, и прочих унизительных приседаний.
S>Что может предложить динамика? Биндить ко всем формам object, а отсутствие Nickname в данных для форма3 выяснять при помощи ручного тестирования?

Не могу понять возможную причину отсутствия Nickname, опечатка? Если да, то действительно тестированием.

S>Те фреймворки, в которых у нас форма биндится прямо к таблице БД — путь в никуда.

Разве ты сейчас не привел код, который биндится прямо к запросу из БД? На мой взгляд это неудобно, например в случае, когда форму надо послать на сервер и вернуть в том же виде, в который привел ее пользователь. В рельсах формы не биндятся ни к таблице ни к запросу, их можно биндить к полям объекта или нескольких.

S>Не вижу, чем бы типизация могла помешать писать такую логику. В первую очередь типизация позволяет отловить ошибки вроде "забыли поселектить атрибут №310 для формы заявления на одобрение кредита" прямо на этапе набора текста в студии, а не через 16 часов запуска nightly build тестов.

В рельсах сложно забыть что-то поселектить. Это заставляет избегать работы с объектами на 310 полей или что-то для этого изобретать дополнительно.

S>Динамика здесь привлекательна тем, что можно просто писать код перекладывания, не заботясь о предварительной декларации всех этих типов и подтипов.

Да нет, в динамике нам не нужно запихивать все данные в какой-то тип. Вот пришел мне хеш строковых параметров, я его запихал в объект прямо строками, объект провалидировался и ушел в БД уже с нужными типами. Тип у меня в коде один и мне не нужно писать для него дюжину DTO с конвертациями туда-сюда.

S>Но грамотная статика обходит динамику и здесь: в ней тоже можно "просто писать код перекладывания", но результат этого кода имеет вполне себе строгий тип (а не "контейнер именованных VARIANT"), и легко можно проверить его на предмет соответствия целевому протоколу.

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

S>Нет, это понятно. Непонятно, как с этим связано отсутствие типизации.

Отсутствие типизации делает код более простым и легко читаемым. Да, ценой несколько меньшей надежности, но более сложный код тоже всегда менее надежен.

S>Ну Linq то будет делать то же самое, и забесплатно, при этом ещё и будет следить за тем, чтобы внезапно not null не стал null.

Будет, Linq отличный инструмент.

S>А можно пример про "сразу понять"? Пока что всё, что я наблюдал краем глаза — это XML конфиг, который описывает XML-конфиг, который описывает, откуда брать конфиг для того, чтобы сконфигурировать то, что нам нужно.

В рельсах вместо конфигов используются соглашения. Это несколько непривычно для тех, кто переходит со статики, но работает хорошо. https://www.netguru.co/blog/service-objects-in-rails-will-help

S>Да, именно эту киллер фичу рельс я и имею в виду. Если её выкинуть из рассмотрения как вредную, то хотелось бы более подробного рассказа про то, как сделать нормальный интерфейс на дотнете.
S>Про джаву не надо — она там застряла в ранних 2000х, с ней соревноваться бессмысленно.

На дотнете? Я в свое время отказался от мысли сделать его на дотнете. По прошествию лет, говорил с разработчиками, они уверены, что выбери мы тогда ASP.NET MVC вместо rails, не уложились бы в сроки и бюджет. Даже несмотря на то, что у нас уже был написанный слой сервера покрытый тестами, который могло использовать веб приложение и все разработчики умели .NET намного лучше рельс.

Вообще нормальный интерфейс это жутко расплывчатое понятие.

S>Вот поэтому ваш опыт и интересен.

Сейчас системе на рельсах три года, в течении которых она активно использовалась и дорабатывалась, добавилась несколько интеграций с другими системами, несколько подсистем для других видов организаций. Количество пользователей возрасло в разы, те пользователи, которые перешли со старой оценивают переход в целом позитивно. Пока полет нормальный, признаков серьезных проблем не наблюдается.

Здравствуйте, Sinclair, Вы писали:

S>Как правило, "бизнес веб-приложения" содержат в товарных количествах CRUD не от хорошей жизни. А в основном, из-за того, что развитие приложения застревает на уровне ER-модели, а на анализ сценариев ресурсов уже не остаётся.
S>В итоге пользователь остаётся наедине с 200 "справочниками", которые надо забивать руками в нужном порядке, чтобы выполнить простейшую бизнес-транзакцию.

Описанная тобой проблема системная и ее решение лежит вне стека технологий.

S>А хотелось ему вовсе не этого, потому что такая работа — это мука. Посмотрите на любое современное клиенто-ориентированное приложение. В основном рекомендую мобильные приложения, т.к. именно там сейчас идёт основная активность, и там применяются передовые UX-концепции. Яндекс-такси — где там Crud? Один уголочек: "история поездок". Какой-нибудь Альфа-Банк посмотрите: вот уж самая что ни на есть традиционная область, brick and mortar.

Яндекс-такси — CRUD — сам заказ, адреса, история поездок. Банк — список платежек, транзакций, выписки. Это все ложится в REST.

К интерфейсу Альфабанка у меня кстати куча претензий по юзабилити. Хз, кто его делал, но на анализ сценариев ресурсов, видимо, не осталось.

S>Нет там никакого Crud. Транзакции типа "открыть депозит", "открыть счёт", "купить облигации ПиФ" — это работа с десятками внутренних табличек. Ничего этого в UI и в помине нету. И не надо — потому что пользователю всё равно, что рублёвые депозиты — это один модуль, а валютные — совсем другой. Что оплата с дебетового счёта — это один вид транзакции, а с кредитной карты — совсем другой. Это всё ненужные подробности.
S>И REST интерфейс никакого отношения к CRUD не имеет. Ну, в том смысле, что он совершенно точно не выставляет наружу структуру табличек БД, что провоцируют делать все убогие CRUD-фреймворки.
S>Он выставляет наружу состояние синтетических ресурсов; они могут ложиться на RDBMS произвольно сложным образом. Хороший фреймворк для этого должен давать мне лёгкие возможности по вот этому отображению туда-сюда. Чтобы PATCH на атрибуты Status и Comment инициировали асинхронную операцию, а не превращался в UPDATE Orders where Id = {0}.

REST это чистый CRUD для HTTP, к табличкам или другим сущностям, не суть важно. В RoR очень легко делать REST по ER модели, но и по другим сущностям его делать не сложнее (как минимум) чем где-то еще.

Рассуждения о том, что фреймворк к чему-то провоцирует, на мой взгляд, не конструктивны. Мы вроде бы уже не дети, чтобы перекладывать ответственность за свои решения в дизайне продукта на фреймворк. Но если тебе очень уж хочется, давай разберем твой пример "PATCH на атрибуты Status и Comment". Как это делается в .net и как в RoR. Напиши свой код, я напишу аналог и сравним трудоемкость.

P.S. Я не сторонник запуска операций по PATCH атрибута. Слишком уж сильно наружу торчат кишки и течет концепция update. Обычно делаю POST /resource/:id/operation. Но это отдельная тема.

Здравствуйте, Ziaw, Вы писали:

S>>Отож. К сожалению, я не могу диктовать сторонним производителям, как именно им писать свой код. Поэтому мне важно быстро обнаружить проблему. Санитизация потенциально косячной информации должна делаться максимально быстро и локально — чтобы я сразу видел "от сервера пришёл какой-то мусор", а не "ой, я пытаюсь получить .length() от null", который вылетает хрен знает где в стеке. Как у нас с этим в динамике типа руби? Или у меня .length() от null волшебно даст тоже null, и проблема будет обнаружена только в интеграционном тесте?
Z>Насколько я понял, статика в данном случае тоже особо не помогла. В динамике это ловится валидацией, которая по коду ничуть не сложнее описания типа, но гораздо мощнее.
Хочется конкретных примеров того, как в динамике сделать валидацию, которая "ничуть не сложнее описания типа".

Z>Не могу понять возможную причину отсутствия Nickname, опечатка? Если да, то действительно тестированием.
Почему опечатка? Рефакторили слой доступа к базе, убрали Nickname из Select, делов-то.

S>>Те фреймворки, в которых у нас форма биндится прямо к таблице БД — путь в никуда.

Z>Разве ты сейчас не привел код, который биндится прямо к запросу из БД?
Почувствуйте разницу между "запросом из БД" и "таблицей БД".

Z>На мой взгляд это неудобно, например в случае, когда форму надо послать на сервер и вернуть в том же виде, в который привел ее пользователь. В рельсах формы не биндятся ни к таблице ни к запросу, их можно биндить к полям объекта или нескольких.
Ок, уже хорошо. Откуда берётся этот объект?

Z>В рельсах сложно забыть что-то поселектить. Это заставляет избегать работы с объектами на 310 полей или что-то для этого изобретать дополнительно.
А почему это сложно?
Z>Да нет, в динамике нам не нужно запихивать все данные в какой-то тип. Вот пришел мне хеш строковых параметров, я его запихал в объект прямо строками, объект провалидировался и ушел в БД уже с нужными типами. Тип у меня в коде один и мне не нужно писать для него дюжину DTO с конвертациями туда-сюда.
По прежнему непонятно, откуда взялась дюжина DTO.
Самый типичный бизнес-код: вот у нас транзакция "заказать продукт Х в бизнес-системе Y". Мы берём пришедшие в запросе данные, дополняем их тем, что вытащено из нашей базы, запихиваем в API системы Y.
Понятное дело, что даже в терминах строковых хешей структура данных "у нас" и "у них" не совпадает. Например, им требуется shipping address; у нас он хранится в customer account. Но имена полей — не совпадают. Кроме того, мы храним страну в виде ISO2, а Y ожидает ISO3.
99% нашего кода — это преобразования вроде

request.ShippingAddress.Line1 = customer.AddressLine1;
request.ShippingAddress.Line2 = customer.AddressLine2;
request.ShippingAddress.Line3 = customer.AddressLine3;
request.ShippingAddress.Country = AddressUtils.Iso2toIso3(customer.CountryCode);

Если у нас слева и справа нетипизированные объекты, то надо докручивать дополнительную валидацию. А если я порефакторил код моего GetCustomer и переименовал или убрал какие-то поля, то я этого не замечу до интеграционного теста.
Причём, заметим, что наша база, в которой хранятся эти "customer", у нас одна, и код GetCustomer один, а систем типа Y — примерно 230, и у каждой свои заскоки и плюшки.
Статика позволяет мне мгновенно понять, сломается ли кто-то из этих систем, если я уберу из Customer поле Culture. В динамике я буду ждать отработки интеграционных тестов со всеми 230 системами, чтобы стриггерить всю валидацию.

Z>Ну да, все проблемы можно решить с помощью магии под названием "писать код", кроме проблемы роста сложности поддержки написанного кода. И начинаются метания в микросервисы и тому подобные дорогие извращения, лишь бы разработка оставалась управляемой.
Я написал очень длинный вариант статического кода выше. Современные версии статически-типизированных языков позволяют мне писать этот бойлерплейт значительно короче.
Что предложит динамика?
Z>Отсутствие типизации делает код более простым и легко читаемым. Да, ценой несколько меньшей надежности, но более сложный код тоже всегда менее надежен.
Ок, давайте сделаем код выше более простым и легко читаемым:

request.ShippingAddress = new Address(){Line1 = customer.AddressLine1,  Line2 = customer.AddressLine2, Line3 = customer.AddressLine3, Country = AddressUtils.Iso2toIso3(customer.CountryCode)}

Что тут может улучшить статика?
На всякий случай: Address — это тип из описания протокола системы Y. Он, собственно, содержит минимальную выжимку, построенную прямо по документации, и никакого бойлерплейта (типа занудных конструкторов):

public class Address
{
  public string Line1 {get;set;}
  public string Line2 {get;set;}
  public string Line3 {get;set;}
  public string Country {get;set;}
}

При желании может быть декорирован атрибутами валидации вроде [NotNull] (пока нет нормальной поддержки NotNull прямо в языке) или [Length(1, 35)].
Искушение выкинуть его и сразу перейти к передаче хеш-массива строковых параметров в HTTP-запрос хорошо подходит для одноразовых скриптов. Если нас беспокоит поддерживаемость хотя бы в течение месяцев, то этот тип окажет нам неоценимую услугу — когда производитель системы Y поменяет протокол, мы отобразим это изменение у нас в классе Address, и очень быстро заметим все места, которые сломаются от этого.

Z>В рельсах вместо конфигов используются соглашения. Это несколько непривычно для тех, кто переходит со статики, но работает хорошо. https://www.netguru.co/blog/service-objects-in-rails-will-help
Спасибо, почитаем.

Z>На дотнете? Я в свое время отказался от мысли сделать его на дотнете. По прошествию лет, говорил с разработчиками, они уверены, что выбери мы тогда ASP.NET MVC вместо rails, не уложились бы в сроки и бюджет. Даже несмотря на то, что у нас уже был написанный слой сервера покрытый тестами, который могло использовать веб приложение и все разработчики умели .NET намного лучше рельс.
Ну, тогда — это тогда. А сейчас?
Z>Вообще нормальный интерфейс это жутко расплывчатое понятие.
На самом деле нет. Просто мало кто изучает книги в этом направлении, и мало у кого есть возможность тестировать различные подходы. Поэтому проще всего сделать вид, что это что-то непознаваемое, и не париться.

Z>Сейчас системе на рельсах три года, в течении которых она активно использовалась и дорабатывалась, добавилась несколько интеграций с другими системами, несколько подсистем для других видов организаций. Количество пользователей возрасло в разы, те пользователи, которые перешли со старой оценивают переход в целом позитивно. Пока полет нормальный, признаков серьезных проблем не наблюдается.
Прикольно.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, Sinclair, Вы писали:

S>>Как правило, "бизнес веб-приложения" содержат в товарных количествах CRUD не от хорошей жизни. А в основном, из-за того, что развитие приложения застревает на уровне ER-модели, а на анализ сценариев ресурсов уже не остаётся.
S>>В итоге пользователь остаётся наедине с 200 "справочниками", которые надо забивать руками в нужном порядке, чтобы выполнить простейшую бизнес-транзакцию.

Z>Описанная тобой проблема системная и ее решение лежит вне стека технологий.
Стек стеку рознь. Когда у человека в руках молоток Delphi с его пришитой реализацией Master/Detail, весь интерфейс приложения превращается в Master/Detail, а бизнес-процессы игнорируются.

Z>Яндекс-такси — CRUD — сам заказ, адреса, история поездок. Банк — список платежек, транзакций, выписки. Это все ложится в REST.
Конечно это ложится в REST. А вот в CRUD — не ложится. Нет таких таблиц в БД, к insert-у в которые сводился бы сценарий "сообщить номер подъезда", или "добавить промежуточные пункты".

Z>К интерфейсу Альфабанка у меня кстати куча претензий по юзабилити. Хз, кто его делал, но на анализ сценариев ресурсов, видимо, не осталось.
Например, какие сценарии вызывают затруднения?

Z>REST это чистый CRUD для HTTP, к табличкам или другим сущностям, не суть важно.
Это как раз очень-очень важно. Потому, что во всех этих Rest и Crud очень важны метаданные. На халяву нам доступны метаданные из СУБД, поэтому очень хочется обойтись ими.
Если мы используем какой-нибудь из старообрядческих ORM, то у нас есть entity-классы вместо таблиц. И опять хочется обойтись именно ими.
Потому что любое другое решение — это боль: надо вот прямо садиться и вручную писать код, который опишет внешний вид формы, его поведение, или то, какие данные мы принимаем и отправляем.
Это значит — надо думать, тратить время. Оптимизация этого времени — вот основная задача фреймворка. Чтобы уменьшить искушение сделать "UI для бедных" или "REST для бедных".

Z>В RoR очень легко делать REST по ER модели, но и по другим сущностям его делать не сложнее (как минимум) чем где-то еще.
Вопрос в том, откуда берутся эти "другие сущности", и каковы механизмы по их порождению и разбору.

Z>Рассуждения о том, что фреймворк к чему-то провоцирует, на мой взгляд, не конструктивны. Мы вроде бы уже не дети, чтобы перекладывать ответственность за свои решения в дизайне продукта на фреймворк. Но если тебе очень уж хочется, давай разберем твой пример "PATCH на атрибуты Status и Comment". Как это делается в .net и как в RoR. Напиши свой код, я напишу аналог и сравним трудоемкость.
Ну, потребуется немножко времени.
Z>P.S. Я не сторонник запуска операций по PATCH атрибута. Слишком уж сильно наружу торчат кишки и течет концепция update. Обычно делаю POST /resource/:id/operation. Но это отдельная тема.
С POST есть проблема идемпотентности. Это, фактически, уход от REST в сторону RPC.

Здравствуйте, Ziaw, Вы писали:

Z>К тебе, как к знатоку вопрос — в торнадо нормально работает hot reload? Можно запустить приложение и потом сутки его дорабатывать, обновляя результат в браузере меньше чем за секунду после внесения изменений в код (бэкенд, фронтэнд, js, стили)?
https://www.tornadoweb.org/en/stable/autoreload.html
торнадо я не знаток — сам пользуюсь другим фрэймворком(dash), но гуглом пользоваться обучен.

Z>Сразу оговорюсь, я плохо знаю торнадо для точного ответа на вопрос, могу что-то лишнего написать.
Я уже понял, что Пастернака ты не читал, но мнение имеешь.

Z>На вскидку по фичам рельс по сравнению с торнадо — CSRF protection, гораздо более декларативный restful роутинг ...
CSRF например https://www.tornadoweb.org/en/stable/guide/security.html
Декларативный роутинг https://www.tornadoweb.org/en/stable/routing.html
WebSockets https://www.tornadoweb.org/en/stable/websocket.html
Остальное TL;DR

Давай ты не будешь просто наваливать, а сам разберешься? Я например указал тебе крутую конкретную фичу, которой в RoR и не пахнет.

Z>То, что вроде не web, но почти всегда нужно — mailers (отправка почты), active jobs (фоновые задачи), active storage (хранение файлов в различных удаленных хранилищах).
Ты не в курсе, что в Питоне есть своя похожая экосистемы с подобными решениями?

Z>То, что не рельсы, а гемы для них, но используется всегда и почти наверняка не имеет аналогов для Торнадо:
Z>Devise — система пользователей с кучей настроек для разных протоколов, регистрация, вспомнить пароль, защита от подбора, oauth.
Z>Cancan — система прав пользователей, декларативное описание и проверка прав на сущности и операции в системе.
И ты уже погуглил и не нашел этого для Торнадо? Например, https://github.com/dsschult/tornado-ldap-JWT-auth или https://github.com/gmr/tinman?

Z>Я в свое время изобретал эти велосипеды для других платформ и примерно знаю, сколько это стоит и насколько легко переносится потом в другой проект.
С web фрэймворками мы разобрались и есть желание поговорить о других велосипедах? Как там в Руби с математикой(numpy/scipy) и анализом данных(pandas)? Про ML упоминать так и быть не буду.

Здравствуйте, Ziaw, Вы писали:

Z>Хочешь сказать, что этот код чем-то заметно отличается в стоимости разработки и поддержки?
Конечно. Куча файлов с интеграцией о которых новичок не знает. Без скаффолдинга ему не обойтись.

N>>Даже если забыть про views, rest-сервисы там останутся фиговые, так как ничего интересней скаффолдингом на ORM не сделать.
Z>Нельзя ли пример? Типа вот в этом случае на рельсах получается фигово, а на питоне я быстрее и лучше сделаю так.
IMXO опытному разработчику должно быть очевидно, что удобная REST-модель не строится автоматической кодогенерацией в ORM на примитивной схеме в RDBMS. Я оставлю дебатирование по этому пункту Sinclair-y, но если принят это за данность, то возникает вопрос о ценность интеграции этой части стека напрямую в RoR/Django.

Z>Ты не понял, я не отказываюсь возиться с рич клиентом. Я говорю про то, что в RoR этот рич клиент (react.js/angular) разрабатывается в одном проекте с бэкэндом. Все прекрасно разрабатывается и деплоится одновременно (и моки писать не нужно). Это удобно.
А где-то это делается не так? И разрабатывать на двух стеках очень неудобно! Поэтому народ и переходит на node.js и делает wasm. Еще можно ничего не знать про react/angular/js и делать красивые клиенты прямо в Питоне, как сделано в dash.

Здравствуйте, Sinclair, Вы писали:

S>Стек стеку рознь. Когда у человека в руках молоток Delphi с его пришитой реализацией Master/Detail, весь интерфейс приложения превращается в Master/Detail, а бизнес-процессы игнорируются.
S>Конечно это ложится в REST. А вот в CRUD — не ложится. Нет таких таблиц в БД, к insert-у в которые сводился бы сценарий "сообщить номер подъезда", или "добавить промежуточные пункты".

Почему к инсерту? Это либо PATCH заказа или POST в его промежуточные пункты. Если нужно объеденить в один запрос — можно и список пунктов в PATCH заказа отдать.

S>Например, какие сценарии вызывают затруднения?

У нас и так ветка развернулась, чтобы уходить от темы. Не хватает как раз REST, например возможности открыть платежку в отдельном окне, только в PDF (я про бизнес). Чем бы здесь помешал R платежки в отдельном окне? Чувству прекрасного, что это master-detail от которого надо бежать? Где мой список контрагентов? Опять бежим от чего-то? Зачем мне список плашек из платежей, каждая из которых разворачивается и сворачивается, кто сказал, что с ним удобно работать?

S>Это как раз очень-очень важно. Потому, что во всех этих Rest и Crud очень важны метаданные. На халяву нам доступны метаданные из СУБД, поэтому очень хочется обойтись ими.
S>Если мы используем какой-нибудь из старообрядческих ORM, то у нас есть entity-классы вместо таблиц. И опять хочется обойтись именно ими.
S>Потому что любое другое решение — это боль: надо вот прямо садиться и вручную писать код, который опишет внешний вид формы, его поведение, или то, какие данные мы принимаем и отправляем.
S>Это значит — надо думать, тратить время. Оптимизация этого времени — вот основная задача фреймворка. Чтобы уменьшить искушение сделать "UI для бедных" или "REST для бедных".

Я предпочитаю делать СУБД так, чтобы сущности хорошо отражали бизнес-процессы. В чем проблема держать в СУБД и заказы такси и их промежуточные пункты? Скорее всего так и сделано. А как бы ты сделал?

Форма всегда пишется вручную, просто в RoR это делается проще с помощью различных хелперов и соглашений.

S>Вопрос в том, откуда берутся эти "другие сущности", и каковы механизмы по их порождению и разбору.

Обычно все равно сущности имеют какую-то привязку к ER, иначе у нас получается странный REST с искусственными ключами. Вот к этой сущности и привязывается. Если в профиле есть адреса, это не значит, что их надо вводить их с переходом на profile/addresses. Но можно и вводить, если так банально удобнее.

S>С POST есть проблема идемпотентности. Это, фактически, уход от REST в сторону RPC.

Это свойство алгоритма операции, можно как PATCH сделать с проблемой идемпотентности, так и POST без нее. Делать вид, что у нас вместо операции перевода заказа в новый статус — update это уход от реальности. Впрочем, если у тебя хорошо получается на PATCHах, это ложится на понятный и поддержиавемый код — ради бога. У меня с этим отношения не сложились.

Здравствуйте, novitk, Вы писали:

N>Конечно. Куча файлов с интеграцией о которых новичок не знает. Без скаффолдинга ему не обойтись.

При чем тут новичок? Новичок на любой платформе ничего хорошего не напишет. Просто потому, что нет опыта, который сын ошибок трудных.

N>IMXO опытному разработчику должно быть очевидно, что удобная REST-модель не строится автоматической кодогенерацией в ORM на примитивной схеме в RDBMS. Я оставлю дебатирование по этому пункту Sinclair-y, но если принят это за данность, то возникает вопрос о ценность интеграции этой части стека напрямую в RoR/Django.

Хорошая REST модель строится вокруг хорошей ER схемы. Со временем, схема может уйти ради быстродействия или еще каких причин, но чтобы отрывать их друг от друга изначально — нужны какие-то серьезные локальные причины. И это единичные случаи. Но это действительно уже предметно обсуждается с Sinclair.

N>А где-то это делается не так? И разрабатывать на двух стеках очень неудобно! Поэтому народ и переходит на node.js и делает wasm. Еще можно ничего не знать про react/angular/js и делать красивые клиенты прямо в Питоне, как сделано в dash.

Народу, который переходит на nodejs, я могу только пожелать попутного ветра и много денег в бюджете. wasm пока диковинка. Про dash ничего не скажу, практические не знаю его, но не думаю, что на этой технологии можно построить что-то серьезное. Как ни странно, но лучше html/css/js до сих пор ничего приличного нет.

Здравствуйте, novitk, Вы писали:

N>торнадо я не знаток — сам пользуюсь другим фрэймворком(dash), но гуглом пользоваться обучен.
N>Я уже понял, что Пастернака ты не читал, но мнение имеешь.

Ну так ты первый начал. И продолжаешь, тот авторелоад, что ты привел, это перезапуск всего сервера при обнаружении изменений на диске. Такой авторелоад хоть на ASP.NET делай, задачка для джуниора. В рельсах авторелоад перегружает код частично и очень быстро. В IDE ставишь сохранение по потере фокуса и тыкаешь обновить браузер на другом мониторе.

Z>>На вскидку по фичам рельс по сравнению с торнадо — CSRF protection, гораздо более декларативный restful роутинг ...
N>CSRF например https://www.tornadoweb.org/en/stable/guide/security.html
N>Декларативный роутинг https://www.tornadoweb.org/en/stable/routing.html
N>WebSockets https://www.tornadoweb.org/en/stable/websocket.html
N>Остальное TL;DR

Роутинг я смотрел, и он совсем не декларативный. CSRF снимаю. Сокеты тоже есть, но как и роутинг, по сравнению с рельсами это конструктор "сделай сам". Я допускаю, что в торнадо есть и еще что-то из моего списка в точно таком же зачаточном состоянии. Я ни за что не возьму это для разработки, потому, что знаю во что выльется. Программисты, вместо того, чтобы реализовывать бизнес фичи будут неделями рассказывать занимательные истории о том, как они меняют колеса на сконструированном велосипеде. Это очень здорово и я сам люблю то чувство, когда велосипед начинает катиться быстрее. Но, черт возьми, дорого.

N>Давай ты не будешь просто наваливать, а сам разберешься?

Я потратил некоторое время, чтобы разобраться, в отличии от тебя.

N>Я например указал тебе крутую конкретную фичу, которой в RoR и не пахнет.

Ну указал и что? Мне с этой сугубо синтетической фичи ни тепло ни холодно.

Z>>То, что вроде не web, но почти всегда нужно — mailers (отправка почты), active jobs (фоновые задачи), active storage (хранение файлов в различных удаленных хранилищах).
N>Ты не в курсе, что в Питоне есть своя похожая экосистемы с подобными решениями?

С подобными. Их надо прикручивать. Потом выясняется, что шаблоны для писем у нас не могут использовать стили и view из приложения.

N>И ты уже погуглил и не нашел этого для Торнадо? Например, https://github.com/dsschult/tornado-ldap-JWT-auth или https://github.com/gmr/tinman?

Конечно. А то, что ты нашел это совсем не то. Что там было про Пастернака?

N>С web фрэймворками мы разобрались и есть желание поговорить о других велосипедах? Как там в Руби с математикой(numpy/scipy) и анализом данных(pandas)? Про ML упоминать так и быть не буду.

Да нет. Ты сделал вил, что уделал RoR с помощью tornado и теперь хочешь соскочить с непонятной тебе веб-разработки на удобную тему "ruby vs python в математике и анализе данных"? Не-не, Девид Блейн. Этот numpy/skipy киллер фича питона, без которой он оставался бы в роли Бейсика. Если мне понадобятся вычисления, я возьму питон или R, но тема не об этом.

Здравствуйте, Ziaw, Вы писали:

Z>Почему к инсерту? Это либо PATCH заказа или POST в его промежуточные пункты. Если нужно объеденить в один запрос — можно и список пунктов в PATCH заказа отдать.
Вы явно путаете реляционный CRUD с глаголами из REST.

Z>У нас и так ветка развернулась, чтобы уходить от темы. Не хватает как раз REST, например возможности открыть платежку в отдельном окне, только в PDF (я про бизнес).
Откуда в мобильном клиенте взялось отдельное окно? Давайте не будем уподобляться коллегам, которые на критику Skype отвечают аргументами про Skype for Business и наоборот.
Я вам говорю про мобильный клиент Альфа-
Z>Чем бы здесь помешал R платежки в отдельном окне?
А сейчас, вы, похоже, путаете REST с SPA, и непонятно откуда берущимися ограничениями на навигацию.
Z>Чувству прекрасного, что это master-detail от которого надо бежать?
Эмм, вы вообще master-detail видели? Ну, чтобы убедиться, что мы об одном и том же говорим?
Z>Где мой список контрагентов? Опять бежим от чего-то? Зачем мне список плашек из платежей, каждая из которых разворачивается и сворачивается, кто сказал, что с ним удобно работать?
Поскольку я приложение, о котором вы говорите, не видел, поэтому комментировать не могу.
Z>Я предпочитаю делать СУБД так, чтобы сущности хорошо отражали бизнес-процессы. В чем проблема держать в СУБД и заказы такси и их промежуточные пункты? Скорее всего так и сделано. А как бы ты сделал?
Я бы не стал делать промежуточные пункты отдельными записями в RDBMS. Это лишние блокировки, лишние заголовки строк. У нас нет запросов, которые бы работали с отдельными промежуточными пунктами. Поэтому я бы сваливал промежуточные пункты как blob поле.
Z>Форма всегда пишется вручную, просто в RoR это делается проще с помощью различных хелперов и соглашений.
Это хорошо, если так. Потому что мне в своё время RoR рекламировали как раз как штуку, которая "клац-клац — и вот смотри, у меня уже таблица заказов, в которую я могу делать вставку и удаление". Ну радость прямо как у первокурсника в 1994, который впервые бросил на форму TDBGrid.
Ничего подобного в яндекс такси нету — и слава байту.

Z>Обычно все равно сущности имеют какую-то привязку к ER, иначе у нас получается странный REST с искусственными ключами. Вот к этой сущности и привязывается. Если в профиле есть адреса, это не значит, что их надо вводить их с переходом на profile/addresses. Но можно и вводить, если так банально удобнее.
Ничего странного в REST с "искусственными ключами" нету. И наличие привязки к ER не означает эквивалентность ER. Эта привязка может быть выполнена большим количеством разнообразных способов.

S>>С POST есть проблема идемпотентности. Это, фактически, уход от REST в сторону RPC.
Z>Это свойство алгоритма операции, можно как PATCH сделать с проблемой идемпотентности, так и POST без нее.
Нет. Почитайте какой-нибудь базовый учебник по REST. У POST есть определённая семантика; если вы хотите сделать при помощи POST идемпотентную операцию, то надо прямо специально приседать. PATCH и PUT обладают идемпотентностью по стандарту — это означает, что во-первых идемпотентность в них гораздо проще реализовать, чем в POST, а во-вторых, что вам не надо отдельно описывать это в документации.
Вот, в Microsoft посоны обычно реализуют идемпотентность при помощи ажно кастом хидера Request ID. Смех сквозь слёзы: 90% их клиентов узнают об этом из ответов в тикет "ой, у нас тут удвоился заказ, как нам этого избежать?".

Z>Делать вид, что у нас вместо операции перевода заказа в новый статус — update это уход от реальности. Впрочем, если у тебя хорошо получается на PATCHах, это ложится на понятный и поддержиавемый код — ради бога. У меня с этим отношения не сложились.
Ну, мне важнее всего код клиента. Потому что сервер — он один, а клиентов — много. С клиента реализовать корректную смену статуса через patch проще, чем через POST и прочее. Мне не надо прикапывать RequestID и прочее — вполне себе тупой клиент способен поддержать смену статуса, не приводя к ошибкам.

Здравствуйте, Sinclair, Вы писали:

S>Вы явно путаете реляционный CRUD с глаголами из REST.

Суть у них одна.

S>Откуда в мобильном клиенте взялось отдельное окно? Давайте не будем уподобляться коллегам, которые на критику Skype отвечают аргументами про Skype for Business и наоборот.
S>Я вам говорю про мобильный клиент Альфа-

Откуда взялся мобильный клиент в теме про веб-фреймворки? Я говорил, что мне не нравится в веб-клиенте бизнеса, который, похоже, делался по принципу — засунем все в одно SPA.

S>А сейчас, вы, похоже, путаете REST с SPA, и непонятно откуда берущимися ограничениями на навигацию.

Нет, я пытаюсь понять, почему "нормальные" интерфейсы не дают мне делать то, что мне нужно.

S>Эмм, вы вообще master-detail видели? Ну, чтобы убедиться, что мы об одном и том же говорим?

Я устал уже от отсылок к delphi, mobile, тонкостей толкования REST. Давай вернемся к теме и разберемся, чем конкретно хороша и плоха динамика в веб-разработке. Не надо мне в каждом посте "тонко" намекать, что твое толкование REST, нормального интерфейса или master-detail чем-то лучше моего. Если что-то считаешь лучшим решением, приведи его, объясни его плюсы, будь готов ответить на вопросы, а все эти намеки свысока "вы вообще master-detail видели" задолбали.

S>Я бы не стал делать промежуточные пункты отдельными записями в RDBMS. Это лишние блокировки, лишние заголовки строк. У нас нет запросов, которые бы работали с отдельными промежуточными пунктами. Поэтому я бы сваливал промежуточные пункты как blob поле.

Понятно. Очень спорно, но не по теме. По теме это укладывается в REST и сценарий PATCH заказа. И вполне нормально вписывается в идеологию RoR.

S>Это хорошо, если так. Потому что мне в своё время RoR рекламировали как раз как штуку, которая "клац-клац — и вот смотри, у меня уже таблица заказов, в которую я могу делать вставку и удаление". Ну радость прямо как у первокурсника в 1994, который впервые бросил на форму TDBGrid.
S>Ничего подобного в яндекс такси нету — и слава байту.

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

Например, разве, делфи оказалась плоха, потому, что можно было бросить грид на форму? Между прочим это был прекрасный инструмент, который был вытеснен C# и .net, как языком так и платформой. Я сам в свое время перешел с радостью, надоело вручную управлять памятью и писать на паскале. Сам редактор форм там был ничуть хуже winforms, а во чем-то даже лучше.

Точно так же я и на RoR ушел. Надоело вручную управлять парком велосипедов. Возможно есть приложения и бизнесы, в которых содержание этого парка оправдано, но мне не нравится аргументация в стиле: "отстутствие необходимости писать велосипед на каждый чих провоцирует нас не писать их совсем, это расслабляет и делает наши приложения неудобными для пользователей". Нужен велосипед — пишем. Преимущество RoR в том, что многое можно брать в готовом виде и кастомизировать ровно то, что нужно.

S> Ничего странного в REST с "искусственными ключами" нету. И наличие привязки к ER не означает эквивалентность ER. Эта привязка может быть выполнена большим количеством разнообразных способов.

Так в чем тогда проблема?

S>Нет. Почитайте какой-нибудь базовый учебник по REST. У POST есть определённая семантика; если вы хотите сделать при помощи POST идемпотентную операцию, то надо прямо специально приседать. PATCH и PUT обладают идемпотентностью по стандарту — это означает, что во-первых идемпотентность в них гораздо проще реализовать, чем в POST, а во-вторых, что вам не надо отдельно описывать это в документации.

Пусть будет PUT, мы опять ушли от темы. Где идемпотентно — PUT, где нет — POST. Если простое изменение данных, в сущность, если это операция — то в операцию. Как это относится к рельсам или .net?

S>Вот, в Microsoft посоны обычно реализуют идемпотентность при помощи ажно кастом хидера Request ID. Смех сквозь слёзы: 90% их клиентов узнают об этом из ответов в тикет "ой, у нас тут удвоился заказ, как нам этого избежать?".

Насколько я понимаю, в этом плане все равно придется что-то изобретать для идемпотентности, хоть POST это будет, хоть PUT, задача программиста сделать идемпотентный обработчик не решается выбором глагола.

S>Ну, мне важнее всего код клиента. Потому что сервер — он один, а клиентов — много. С клиента реализовать корректную смену статуса через patch проще, чем через POST и прочее. Мне не надо прикапывать RequestID и прочее — вполне себе тупой клиент способен поддержать смену статуса, не приводя к ошибкам.

Чем проще-то? Не могу понять. Ну кроме того, что не надо дополнительно документировать идемпотентность.

Давай закругляться. В теме уже нет конструктива, все что я услышал, про RoR в этом посте — у тебя большой скепитизим в том, что RoR подходит для бэкенда Яндекс.Такси. В этом я даже с тобой готов согласиться, когда сущностей немного, процессы известны и стоит задача сделать надежное как космический корабль и такое же быстрое серверное приложение, рельсы не лучший выбор. Хотя опять же есть нюансы, есть примеры крупных торговых площадок даже на PHP. Значит можно и даже чем-то для них оправдано.

Все остальное — тонкости понимания REST, предпочтения в UI, что там было в Delphi, идут параллельно теме и тоже совсем не конструктивно. Ты занял позицию гуру — кругом говно, читайте книги, там все рассказано. Я не просил совета, какие книги мне читать.