Comments 78
Для гимна краткости пост слегка великоват.
«Я пишу какое-то коммерческое предложение и мне надо «Выкнуть» или это ответ на рядовое письмо и достаточно простого «вы»» — перфекционист по определению должен в совершенстве знать правила родного языка и пользоваться ими (если Вы не русский человек — вычеркните это предложение).
«Я пишу какое-то коммерческое предложение и мне надо «Выкнуть» или это ответ на рядовое письмо и достаточно простого «вы»» — перфекционист по определению должен в совершенстве знать правила родного языка и пользоваться ими (если Вы не русский человек — вычеркните это предложение).
«Вы» с заглавной − это глупость. Перфекционизм требует избавляться от общепринятых глупостей.
Просто слова — это глупость. Известно, что практически любую действительно важную мысль русский человек может выразить только при помощи междометий, предлогов-союзов и единственного слова из 3 букв. Префекционисты должны отбросить общепринятые глупости и изъясняться только так.
Слово «Вы» с заглавной несет другой смысл, нежели, чем такое же слово «вы» без заглавной.
По правилам русского языка местоимение «вы» можно использовать как в обращении к одному лицу, так и к нескольким. Само по себе употребление «вы» вместо «ты» свидетельствует об уважении. В чём тогда выражается этот «другой смысл»?
Если слово «вы» используется как обращение к неопределённому кругу лиц (типа «уважаемый читатель»), то такое обращение принято писать со строчной буквы. Если слово «вы» используется для показания уважения при обращении к конкретному адресату (автор заранее знает человека, которому лично адресует текст), то его принято писать с заглавной. Также допускается авторский выбор. Т.е., автор может написать и личное обращение со строчной буквы, вкладывая в это намёк либо на не особо уважительное отношение к читателю, либо на маргинальную точку зрения относительно норм использования русского языка. Или при обращении к неопредлённому кругу лиц автор может использовать прописную букву, чтобы немного польстить любому из неопределённого круга лиц читателей (используется, как правило, в рекламе или пропаганде).
Это взято из какого-то источника или ваше собственное понимание? В моих источниках другая информация:
Источники:
- «вы» при обращении к одному человеку допустимо по усмотрению автора и не является никаким намёком или маргинализацией,
- «Вы» при обращении к нескольким лицам − банальная орфографическая ошибка.
Источники:
Да, верно, информация именно из вашей первой ссылки. Только, пожалуйста, не нужно побуквенного сканирования текстов, я уверен, что вы поняли границы и степень необязательности используемых правил и с моими ироничными замечаниями об уважении грамматических нацистов.
1) Употребление местоимения вы вместо ты при обращении к одному лицу само по себе уже представляет проявление уважительного отношения к этому лицу. Окончательное решение о написании Вы с прописной (для подчеркивания этого уважительного отношения) принимает автор текста.
2) Таким образом, местоимения Вы, Ваш пишутся с прописной буквы при обращении к одному лицу в текстах следующих жанров: [...] анкеты, рекламные листовки (текст, адресованный неконкретному лицу).
1) Употребление местоимения вы вместо ты при обращении к одному лицу само по себе уже представляет проявление уважительного отношения к этому лицу. Окончательное решение о написании Вы с прописной (для подчеркивания этого уважительного отношения) принимает автор текста.
2) Таким образом, местоимения Вы, Ваш пишутся с прописной буквы при обращении к одному лицу в текстах следующих жанров: [...] анкеты, рекламные листовки (текст, адресованный неконкретному лицу).
Я напомню: в комментарии, на который вы ответили, и выше по треду речь шла не о правиле орфографии, а о смысле, который сообщает заглавная буква.
Скорее всего, мы с вами по-разному поняли слово «смысл» в этом контексте.
Я имел в виду смысл, который, например, сообщает слову «всё» две маленькие точечки над буквой «е». Правилами разрешается их не ставить, но смысл слова от этого меняется. А между «вы» и «Вы» такой разницы в смысле не может быть.
Скорее всего, мы с вами по-разному поняли слово «смысл» в этом контексте.
Я имел в виду смысл, который, например, сообщает слову «всё» две маленькие точечки над буквой «е». Правилами разрешается их не ставить, но смысл слова от этого меняется. А между «вы» и «Вы» такой разницы в смысле не может быть.
> А между «вы» и «Вы» такой разницы в смысле не может быть.
Может, и разница в смысле объяснена в вашей первой ссылке и процитирована мною из неё же в ответ. У вас навязчивая идея, вы считаете некоторое правило «логичным», отрицая действительное (зафиксированное лингвистами) положение вещей в языке. Возможно, скоро таких «логиков» накопится критическое число, и правила немного упростят/подкорректируют, чтобы синхронизировать академические источники с реальным опытом носителей языка. Как произошло с кофием и шампунью в своё время, например.
Может, и разница в смысле объяснена в вашей первой ссылке и процитирована мною из неё же в ответ. У вас навязчивая идея, вы считаете некоторое правило «логичным», отрицая действительное (зафиксированное лингвистами) положение вещей в языке. Возможно, скоро таких «логиков» накопится критическое число, и правила немного упростят/подкорректируют, чтобы синхронизировать академические источники с реальным опытом носителей языка. Как произошло с кофием и шампунью в своё время, например.
Ну так вполне логично для «логиков» пропагандировать «логичные» варианты как логичные, чтобы быстрее накопилось критическое число употреблений и новая (или хорошо забытая старая) языковая норма сначала стало нормой де-факто, а потом была и зафиксирована «де-юре» в академических словарях.
Кто-то запрещает это делать? Я всего лишь указал на отличие желаемого от действительного. Т.е., «логикам» пока рано говорить, что они уже добились переписывания учебников, т.к. пока не добились. Вне зависимости от моего личного отношения к слову «вы».
неверно.
«вы» надо писать с маленькой буквы за редкими исключениями
«вы» надо писать с маленькой буквы за редкими исключениями
Глупость сказали. Перфекционизм — стремление к совершенству. Все что дальше — сугубо относительно. Что вы выберете эталоном, то и будет.
Нет, совершенствование в заведомо низком искусстве подхалимажа не может быть вызвано перфекционизмом. А иного смысла, кроме подхалимства, «Вы» на письме не имеет.
То ли дело «я» в английском, да?
В принципе, и предложения начинать с заглавной буквы, и пробел после знака препинания, а не перед, это излишества. Да и Васю незачем с заглавной писать — побудет васей, не облезет.
В принципе, и предложения начинать с заглавной буквы, и пробел после знака препинания, а не перед, это излишества. Да и Васю незачем с заглавной писать — побудет васей, не облезет.
>Нет, совершенствование в заведомо низком искусстве подхалимажа не может быть вызвано перфекционизмом
Можете привести какие-то аргументы в защиту этого утверждения, кроме собственных убеждений? Если нет, то — мимо.
> А иного смысла, кроме подхалимства, «Вы» на письме не имеет.
https://ru.wikipedia.org/wiki/%D0%92%D1%8B
>также употребляется при вежливом или официальном обращении к одному лицу
>Правила орфографии указывают случаи, когда местоимения «вы», «ваш» (во всех падежах и родах) в середине предложения пишутся с заглавной (прописной) буквы:
>как форма выражения вежливости при обращении к одному конкретному лицу в личной переписке, официальных документах и т. п., напр.: Поздравляем Вас…, Сообщаем Вам…; в ответ на Ваш запрос…;
>при официальном титуловании оба слова в сочетаниях Ваше (Его, Её) Величество, Ваше (Его, Её) Высочество[4].
Можете привести какие-то аргументы в защиту этого утверждения, кроме собственных убеждений? Если нет, то — мимо.
> А иного смысла, кроме подхалимства, «Вы» на письме не имеет.
https://ru.wikipedia.org/wiki/%D0%92%D1%8B
>также употребляется при вежливом или официальном обращении к одному лицу
>Правила орфографии указывают случаи, когда местоимения «вы», «ваш» (во всех падежах и родах) в середине предложения пишутся с заглавной (прописной) буквы:
>как форма выражения вежливости при обращении к одному конкретному лицу в личной переписке, официальных документах и т. п., напр.: Поздравляем Вас…, Сообщаем Вам…; в ответ на Ваш запрос…;
>при официальном титуловании оба слова в сочетаниях Ваше (Его, Её) Величество, Ваше (Его, Её) Высочество[4].
Можете привести какие-то аргументы в защиту этого утверждения
Во-первых, с точки зрения логики заглавная буква в «Вы» лишняя: обращение «вы» по сравнению с «ты» и так является уважительным. Масло масляное.
Во-вторых, ситуация с «Вы» («Ваш») и «вы» (ваш) довольно уникальная: никаких аналогий с правописанием других слов тут привести нельзя. А литературные языки стремятся к унификации правил, поэтому с «Вы» как наиболее надуманной формой обращения мы всё равно скоро попрощаемся.
В-третьих, не я один не люблю «Вы», то есть процесс очищения языка от излишней вычурности уже пошёл.
мая твая панимать! скора вся наша будет така говорить. проста и панятна. лишняя сложнастя не нужна. процесса уже пошла.
Не вы (я умышленно пишу по-вашему уровню, чтобы вы поняли) один не дружите с русским языком. И не вы один пренебрегаете вежливостью, в том числе и при переписке.
Но повода гордиться этим я не вижу.
Но повода гордиться этим я не вижу.
Артемий Лебедев § 165. Три правила про вы
www.artlebedev.ru/kovodstvo/sections/165
www.artlebedev.ru/kovodstvo/sections/165
А мне кажется, что вы передёргиваете и паясничаете. Уж не знаю, умышленно или нет.
Вы сами за меня решили, что я то ли не люблю придерживаться правил языка, то ли являюсь сторонником перехода на фонетическую орфографию. Разумеется, это всё мимо.
Вы сами за меня решили, что я то ли не люблю придерживаться правил языка, то ли являюсь сторонником перехода на фонетическую орфографию. Разумеется, это всё мимо.
Без перехода на личности, но все же… ощущение подобных нюансов это результат сложившейся культуры общения у конкретного человека. Он повышается через общение с соответствующем окружением, чтение книг и т.п.
А что по теме, то для меня различие между «Вы» и «вы» — в степени дистанцированности от человека (знаком я с ним лично или нет; хочу ли я выделить формальность своего обращения), либо желании особо подчеркнуть его статус в моих глазах.
А что по теме, то для меня различие между «Вы» и «вы» — в степени дистанцированности от человека (знаком я с ним лично или нет; хочу ли я выделить формальность своего обращения), либо желании особо подчеркнуть его статус в моих глазах.
>Во-первых, с точки зрения логики заглавная буква в «Вы» лишняя: обращение «вы» по сравнению с «ты» и так является уважительным. Масло масляное.
«вы» с маленькой буквы используется на письме как обращение к множественному лицу. «Вы» с заглавной — к единственному. Банальное разделение для удобства при письме.
Банальный пример (импровизация на тему письма в контору «Рога и Копыта», письмо адресовано конкретному адресату А):
«Уведомляю вас, что с первого числа сего месяца, вы должны подавать документ Д не позднее двадцатого числа каждого месяца»
Кого «вас»? Компанию или адресата?
Кто «вы»? Лично «он(а)» со своей подписью и паспортом должен явиться в органы или компания через юридический (или какой-то другой) отдел должна подавать документы?
Ситуация, по сути, такая же каки с е\ё — в большинстве случаев вполне очевидно, что имеется ввиду и люди про букву ё уже начинают забывать.
Пример немного утрирован для наглядности.
«вы» с маленькой буквы используется на письме как обращение к множественному лицу. «Вы» с заглавной — к единственному. Банальное разделение для удобства при письме.
Банальный пример (импровизация на тему письма в контору «Рога и Копыта», письмо адресовано конкретному адресату А):
«Уведомляю вас, что с первого числа сего месяца, вы должны подавать документ Д не позднее двадцатого числа каждого месяца»
Кого «вас»? Компанию или адресата?
Кто «вы»? Лично «он(а)» со своей подписью и паспортом должен явиться в органы или компания через юридический (или какой-то другой) отдел должна подавать документы?
Ситуация, по сути, такая же каки с е\ё — в большинстве случаев вполне очевидно, что имеется ввиду и люди про букву ё уже начинают забывать.
Пример немного утрирован для наглядности.
Перфекционист должен испытывать желание улучшить правила языка, которым пользуется. А еще он, как правильно заметил автор, должен испытывать желание оптимизировать свое общение. С этой точки зрения — автор абсолютно прав.
Используя «Вы» в этом комментарии, вы как бы показываете, что вы не перфекционист?
Что насчёт CORS (https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS)?
Поддерживается «из коробки».
Автор, держи наркоманское пять! Я также всем повторяю, что умение упрощать — один из главных навыков, приобретаемых с опытом и главный абстрактный маркер профессионализма. Тулза — прикольная. Хотелось бы поинтересоваться у знающих людей, есть ли что-то подобное на Go?
Есть отличные плагины для браузеров (тот же postman в google chrome), намного практичнее, удобнее добавлять заголовки, есть история и.т.п.
Есть bat, «inspired by httpie».
С jsonapi.org совместимо?
Как фреймворк стыкуется с реляционными БД?
ps: про «вы с маленькой» писать не надо было. Не имеет отношения к теме, только лишний холивар.
ps: про «вы с маленькой» писать не надо было. Не имеет отношения к теме, только лишний холивар.
Есть поддержка SQLAlchemy с помощью плагина.
Я принципиально всем «выкаю»
Мы с женой разговариваем на «вы», так что я вас понимаю в этом плане )
Всё написанное до Введения поглотилось на одном дыхании, ибо качественных статей с примерами на тему «упрощай» явно недостаточно.
И тут, внезапно, программирование. ;)
Может напишете общую статью?
И тут, внезапно, программирование. ;)
Может напишете общую статью?
Мне кажется Django REST Framework или Yii2 REST даст гораздо больше возможностей из коробки, так как там помимо чистого API сразу вам будет и админка и миграции базы и всё то, что умеет этот фреймворк + кучу плагинов и большее сообщество.
Но это имхо. Если же действительно есть БД и нужно лишь апи к ней, то Eve конечно имеет право на существование.
Но это имхо. Если же действительно есть БД и нужно лишь апи к ней, то Eve конечно имеет право на существование.
Речь идёт о простоте. Кодовую базу Django я бы простой не назвал. Eve построен на Flask, куча плагинов у него тоже есть и с сообществом нет проблем.
С ORM тоже непонятно. Если он мне не нужен? Лично я вообще уже забыл когда мне надо было использовать реляционную БД, а вот репликацию и шардинг я использую почти во всех своих проектах.
Про Yii2 я ничего сказать не могу, PHP руками не трогаю.
С ORM тоже непонятно. Если он мне не нужен? Лично я вообще уже забыл когда мне надо было использовать реляционную БД, а вот репликацию и шардинг я использую почти во всех своих проектах.
Про Yii2 я ничего сказать не могу, PHP руками не трогаю.
Из коробки в Django REST Framework'е из всего перечисленного разве что сериализация в json/xml есть.
Впрочем eve тоже выглядит подозрительно просто.
Интересно можно ли сделать CQRS на Eve, что бы так же просто было?!
Впрочем eve тоже выглядит подозрительно просто.
Интересно можно ли сделать CQRS на Eve, что бы так же просто было?!
а где контроллеры? где писать бизнес логику? кастомная валидация? что-то сложнее «удалённой db по http» на этом написать можно?
Есть всё, что вы указали и ещё больше. Построен фреймворк на базе Flask, так что вы можете использовать все его возможности. Пример кастомной валидации. Помимо возможностей Flask, вы можете описать логику и привязать к событиям Eve.
Спасибо, очень хорошая статья. API — моя любимая тема для дискуссий. Очень мощная штука этот Eve, список возможностей радует глаз.
И за тулзу отдельное спасибо, меня каждый раз curl в ступор вводит, когда надо руками запрос написать.
И за тулзу отдельное спасибо, меня каждый раз curl в ступор вводит, когда надо руками запрос написать.
UFO just landed and posted this here
Смотрел я на Python Eve некоторое время назад и знаете, у меня был опыт наступания на подобные грабли — Pinax назывались эти грабли. Всё это дело работает до поры до времени, пока у вас какой-нибудь хитрый случай не вылезет, где простым SELECT/UPDATE не отделаешься и начнётся «сладкая жизнь». Это ещё не говоря о том, что dict с конфигом разрастается в реальном проекте мама не горюй и подстветка синтаксиса такому коду уже не поможет.
Кстати, интерфейсы взаимодействия в Eve меня пугают — JSON в GET параметрах выглядит странно, HATEOAS тоже не панацея (люди решили почему-то, что обязательно нужно иметь ссылки в API, но API используют машины и они не будут принимать никаких решений на основании содержимого ответа, они могут составить ссылки самостоятельно, в отличие от «кликающего пользователя»).
P.S. Мои личные поиски «идеального» инструмента завершились на Flask-RESTplus, в котором, пожалуй да, приходится писать чуть больше кода, но зато есть возможность сделать то, что нужно и где нужно. Я в итоге собрал минимальный пример REST API сервера
Кстати, интерфейсы взаимодействия в Eve меня пугают — JSON в GET параметрах выглядит странно, HATEOAS тоже не панацея (люди решили почему-то, что обязательно нужно иметь ссылки в API, но API используют машины и они не будут принимать никаких решений на основании содержимого ответа, они могут составить ссылки самостоятельно, в отличие от «кликающего пользователя»).
P.S. Мои личные поиски «идеального» инструмента завершились на Flask-RESTplus, в котором, пожалуй да, приходится писать чуть больше кода, но зато есть возможность сделать то, что нужно и где нужно. Я в итоге собрал минимальный пример REST API сервера
люди решили почему-то, что обязательно нужно иметь ссылки в API, но API используют машины и они не будут принимать никаких решений на основании содержимого ответа, они могут составить ссылки самостоятельно, в отличие от «кликающего пользователя»
Люди решили почему-то, что обязательно нужно иметь ссылки в HTML, но HTML используют машины и они не будут принимать никаких решений на основании содержимого ответа, они могут составлять ссылки самостоятельно, в отличие от «кликающего пользователя».
А если серьёзно, то HATEOAS — это попытка, как минимум, частично стандартизировать автоматические правила составления ссылок. Самое очевидное применение — одновременно с представлением ресурса получить и список доступных текущему пользователю операций.
одновременно с представлением ресурса получить и список доступных текущему пользователю операций.Ну и что, скажем, мобильное приложение будет с этой информацией по «доступным пользователю действиям» делать? Кнопки дорисовывать автоматически? Вот более развёрнутая мысль — Best Practices for Designing a Pragmatic RESTful API: Should you HATEOAS?
Не рисовать недоступные кнопки или рисовать их неактивными, чтобы не смущать пользователя кнопкой, по нажатию на которую он получает представление 403, 405 или иной ошибки.
Таким образом ответ нельзя закешировать, так как для разных пользователей будут отсутствовать некоторые ссылки, да и даже для одного пользователя нельзя закешировать — вдруг ему права урезали/добавили — инвалидировать кеш запаришься. Да и вообще, как по мне, то мухи должны быть отдельны от котлет. Хотите узнать какие действия можно производить над объектами — спросите об этом отдельно. Объект — это объект, а действия над ним — это отдельная история.
В терминах ООП объект и действия неотделимы :)
Даже в ООП вы не полезете в данные объекта за информацией о том что разршено делать с объектом, а спросите об этом у модуля безопасности, который, конечно, уже сам может решить проинспектировать запрашиваемый объект. Такой «модуль безопасности» в терминах RESTful API, как мне кажется, принято реализовывать по HTTP-запросу OPTIONS.
(люди решили почему-то, что обязательно нужно иметь ссылки в API, но API используют машины и они не будут принимать никаких решений на основании содержимого ответа, они могут составить ссылки самостоятельно, в отличие от «кликающего пользователя»).
Они всегда будут принимать решение на основании содержимого ответа. HATEOAS даёт возможность не плодить v1/v2/v3/v1000, для случаев, когда там просто изменился один URL. Можно «хардокить» везде ссылки и пересобирать мобильные приложение и фронтенд каждый раз, если так удобнее.
Если говорить о каком-нибудь инструменте автоматического генерирования админки, то без HATEOAS там вообще обойтись не получится.
Кстати, интерфейсы взаимодействия в Eve меня пугают — JSON в GET параметрах выглядит странно
Не буду отрицать.
Всё это дело работает до поры до времени, пока у вас какой-нибудь хитрый случай не вылезет, где простым SELECT/UPDATE не отделаешься и начнётся «сладкая жизнь».
Вы документацию читали? Есть "хуки" на каждое событие, если их их мало, то есть все возможности Flask. Вы же сами дальше пишите, что Flask используете.
Давно работаю с Eve и такого рода проблем точно не встречал.
Это ещё не говоря о том, что dict с конфигом разрастается в реальном проекте мама не горюй и подстветка синтаксиса такому коду уже не поможет.
Есть альтернативные, более короткие, варианты описания моделей? Большой конфиг, разделите его на модели, модели опишите в YAML и всё будет здорово.
Или вам удобнее модели в Django кодом описывать?
Они всегда будут принимать решение на основании содержимого ответа. HATEOAS даёт возможность не плодить v1/v2/v3/v1000, для случаев, когда там просто изменился один URL. Можно «хардокить» везде ссылки и пересобирать мобильные приложение и фронтенд каждый раз, если так удобнее.Для случая просто смены URL я оставляю старый URL, в документации помечаю deprecated, а в следующей версии, когда других изменений уже накопилось много — удаляю.
Если говорить о каком-нибудь инструменте автоматического генерирования админки, то без HATEOAS там вообще обойтись не получится.По The OpenAPI Specification (fka The Swagger Specification) строить админку куда легче, чем ходить по всем URL.
Вы документацию читали? Есть «хуки» на каждое событие, если их их мало, то есть все возможности Flask. Вы же сами дальше пишите, что Flask используете.Хуки хуками, а бизнес логику куда девать? Её не существует? Самое первое препятствие — роли пользователей, в частности «владелец» объекта и «менеджер», который имеет доступ в том числе ко всем объектам своих подчинённых (в простом случае). Вот так я это реализовал в своём примере — github.com/frol/flask-restplus-server-example/blob/master/app/modules/teams/resources.py#L79
Или вам удобнее модели в Django кодом описывать?Да, почему-то в коде мне их удобнее описывать, могу использовать наследования, например: github.com/frol/flask-restplus-server-example/blob/master/app/modules/teams/schemas.py
Для случая просто смены URL я оставляю старый URL, в документации помечаю deprecated, а в следующей версии, когда других изменений уже накопилось много — удаляю.
Ну об этом и речь. Я не буду ничего помечать «deprecated» и удалять в следующей версии. Я просто поменяю URL.
По The OpenAPI Specification (fka The Swagger Specification) строить админку куда легче, чем ходить по всем URL.
Я не такой любитель стандартов и спецификаций. В начале статьи я написал о простоте, мне чем проще, тем лучше.
Я 2.5 года работаю в стартапе без выходных, каждый день по 12-14 часов, иногда и того больше. Работы с каждым днём меньше не становится и если бы я каждый раз тратил на задачу больше времени, чем требуется, хотя бы на чуть-чуть, то стартап закрылся бы уже давно, а я лежал в больнице с переутомлением.
Хуки хуками, а бизнес логику куда девать? Её не существует? Самое первое препятствие — роли пользователей, в частности «владелец» объекта и «менеджер», который имеет доступ в том числе ко всем объектам своих подчинённых (в простом случае).
Стандартная задача, решается легко. Вариантов реализации много, примеры можно найти в официальной документации.
Да, ещё меня в Python Eve удивила реализация PATCH. Please. Don't Patch Like An Idiot. — William Durand. Если кратко, то есть RFC 6902, а в Eve решили придумать свой велосипед. (Кстати, в моём примере RESTful API сервера, по ссылке выше, PATCH реализован как рекомендует RFC)
Это решили не в Python Eve. Я часто встречал такое использование и это уже, похоже, внегласное соглашение. Всё, как обычно для простоты использования. Посмотрите на примеры из статьи, которую вы привели в пример:
Так они хотят вносить изменения в JSON. Для XML предлагают вообще XML Path использовать. Но мне надо просто изменить значение, я не хочу ничего знать об XML Patch. Завтра вам понадобится использовать какой-нибудь другой формат данных, например YAML и надо будет придумать свой велосипед. Это если закрыть глаза на то, что составление такого запроса на порядок сложнее и не упростит реализацию мобильного клиента. А парсинг таких запросов на сервере, их валидация и обработка буду занимать больше времени.
У меня был опыт разработки WebDAV, в котором используется много стандартов. Также имел опыт создания CalDAV и CardDAV, которые являются дополнениями к WebDAV и могу вам сказать следующее: никто и никогда полностью не соблюдает стандарты, в особенности, когда они сложны. Реализация более-менее функционального сервиса WebDAV превращается в большую кучу патчей для всех распространённых клиентов.
Если вы попробуете использовать штатный WebDAV клиент Windows/OS X, то вряд ли найдёте хотя бы несколько серверов, с которыми у вас не будет проблем. Про CalDAV/CardDAV клиентов я промолчу. А ведь всё описано стандартами.
В общем сделали так, как более логично. Правильно это или нет, решать не мне. Но я бы поступил так же.
Стандарты это круто, пока следуют им другие.
[
{ "op": "test", "path": "/a/b/c", "value": "foo" },
{ "op": "remove", "path": "/a/b/c" },
{ "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
{ "op": "replace", "path": "/a/b/c", "value": 42 },
{ "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
{ "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
]
Так они хотят вносить изменения в JSON. Для XML предлагают вообще XML Path использовать. Но мне надо просто изменить значение, я не хочу ничего знать об XML Patch. Завтра вам понадобится использовать какой-нибудь другой формат данных, например YAML и надо будет придумать свой велосипед. Это если закрыть глаза на то, что составление такого запроса на порядок сложнее и не упростит реализацию мобильного клиента. А парсинг таких запросов на сервере, их валидация и обработка буду занимать больше времени.
У меня был опыт разработки WebDAV, в котором используется много стандартов. Также имел опыт создания CalDAV и CardDAV, которые являются дополнениями к WebDAV и могу вам сказать следующее: никто и никогда полностью не соблюдает стандарты, в особенности, когда они сложны. Реализация более-менее функционального сервиса WebDAV превращается в большую кучу патчей для всех распространённых клиентов.
Если вы попробуете использовать штатный WebDAV клиент Windows/OS X, то вряд ли найдёте хотя бы несколько серверов, с которыми у вас не будет проблем. Про CalDAV/CardDAV клиентов я промолчу. А ведь всё описано стандартами.
В общем сделали так, как более логично. Правильно это или нет, решать не мне. Но я бы поступил так же.
Стандарты это круто, пока следуют им другие.
Сложно? Да, чуть сложнее, чем решение в лоб, зато расширяемо. Не нравится RFC — напишите свою, но реализация «мне так нравится» подходит для своего личного пользования, а для фреймворка — это минус. OpenAPI (Swagger) спецификацией можно описать любой каприз и после этого у вас будет и интерактивная документация, и автогенерируемые клиенты на куче языков, но Eve не пошёл путём интеграции с Swagger, так что да, написать сервер просто, но потом клиента к нему писать придётся самому и работать с особенностями Eve на клиенте — тоже.
Опять же, можете у меня в примере посмотреть и как это выглядит в Swagger документации (Docker образ поднимается за полминуты), и в коде (я пока не оформил этот случай в отдельную обёртку, но думаю об этом), и в:
Опять же, можете у меня в примере посмотреть и как это выглядит в Swagger документации (Docker образ поднимается за полминуты), и в коде (я пока не оформил этот случай в отдельную обёртку, но думаю об этом), и в:
OpenAPI (Swagger) Specification JSON, который автоматически собирается Flask-RESTplus
"patch": {
"description": "**PERMISSIONS: Owner/Supervisor/Admin may execute this action.**",
"operationId": "patch_team_by_id",
"parameters": [
{
"in": "path",
"name": "team_id",
"required": true,
"type": "integer"
},
{
"in": "body",
"name": "body",
"required": true,
"schema": {
"items": {
"properties": {
"op": {
"enum": [
"add",
"test",
"remove",
"replace"
],
"location": "json",
"type": "string"
},
"path": {
"enum": [
"/title"
],
"location": "json",
"type": "string"
},
"value": {
"location": "json",
"type": "string"
}
},
"required": [
"op",
"path"
]
},
"location": "json",
"type": "array"
}
}
],
"responses": {
"200": {
"description": "Success",
"schema": {
"$ref": "#/definitions/DetailedTeamSchema"
}
},
"401": {
"description": "Authentication with teams:write scope(s) is required",
"schema": {
"$ref": "#/definitions/401HTTPErrorSchema"
}
},
"403": {
"description": "Owner/Supervisor/Admin may execute this action.",
"schema": {
"$ref": "#/definitions/403HTTPErrorSchema"
}
},
"404": {
"description": "Team not found.",
"schema": {
"$ref": "#/definitions/404HTTPErrorSchema"
}
},
"409": {
"description": "A conflict happened while processing the request. The resource might have been modified while the request was being processed.",
"schema": {
"$ref": "#/definitions/409HTTPErrorSchema"
}
},
"422": {
"description": "The request was well-formed but was unable to be followed due to semantic errors.",
"schema": {
"$ref": "#/definitions/422HTTPErrorSchema"
}
}
},
"security": [
{
"oauth2": [
"teams:write"
]
}
],
"summary": "Patch team details by ID",
"tags": [
"teams"
]
}
Я не буду рассуждать на тему: правильно/неправильно. Я не разработчик фреймворка и не учавствовал в создании стандартов. Я выражаю лишь своё мнение — я считаю вариант Eve удобнее. Более того, вариант Eve используется в большинстве случаев.
Тоже самое можно сказать и о вашей спецификации и придерживаться её – сложнее. Хотя бы потому, что она сама на порядок сложнее. По крайней мере для меня.
но потом клиента к нему писать придётся самому и работать с особенностями Eve на клиенте — тоже
Тоже самое можно сказать и о вашей спецификации и придерживаться её – сложнее. Хотя бы потому, что она сама на порядок сложнее. По крайней мере для меня.
Для клиента из OpenAPI (Swagger) Specification (официальный пример PetStore API) генерируется ООП модуль/библиотека (вот что генерируется автоматически для Python), так что на клиенте даже не нужно возиться с URL, парсингом или другим, а просто сразу приступаешь к работе с объектами, что-то в духе:
from petstore_swagger_api import PetApi
pet_api = PetApi()
available_pets = pet_api.find_pets_by_status(status='available')
Перфекционист на маке? О_о или в прелюдии не ваши скриншоты?)
А по поводу перфекционизма я задумался после прочтения недавних статей на хабре или гиктаймзе про эволюцию и глаз, на сколько он не совершенен, и то что мы так хорошо видим это доработка хаками… если мы по натуре не совершены стоит ли идти к совершенству, какая-то такая филосовская мысль, перфекционистом сложно жить )
А по поводу перфекционизма я задумался после прочтения недавних статей на хабре или гиктаймзе про эволюцию и глаз, на сколько он не совершенен, и то что мы так хорошо видим это доработка хаками… если мы по натуре не совершены стоит ли идти к совершенству, какая-то такая филосовская мысль, перфекционистом сложно жить )
Пытаюсь повторить примеры,
Не подскажете, где могла собака порыться?
http htp://127.0.0.1:5000/
http http://127.0.0.1:5000/usersНе подскажете, где могла собака порыться?
Если человек вам не может объяснить даже трудную для понимания тему простым языком, значит, он сам не до конца понимает о чём говорит.
Пожалуй эту фразу я сохраню в цитатнике.
Этот тезис (как и многие другие «простые истины») практически бесполезен (и даже вреден) в реальной жизни. Это чрезмерное упрощение. http://lesswrong.ru/w/Ожидая_короткие_понятийные_расстояния
Расскажите об этом Стиву Возняку. Отец ему начал рассказывать принципы электротехники, когда он еще не достиг четырех лет.
Я не думаю, что по прошествии года, в пять лет, Стив стал профессионально разбираться в "принципах электротехники". Всё же есть разница между идеей "передать информацию из одной головы в другую" и "заинтересовать новичка, не используя сложных терминов и приводя интересные примеры да аналогии". Ну и, справедливости ради, я не знаю, что именно говорил Возняку его отец.
Спасибо. Полезный инструмент, намного удобнее Django REST Framework. Жаль, нет интеграции с Django.
P.S.
P.S.
Упс, ошибка. Я выше упоминал о целостности данных.ссылка битая.
Sign up to leave a comment.
Полноценный REST API для перфекционистов за 5 минут