А к чему апи?

к хостеру

и логика на бекенде

там выдача ресурсов, подсети, всякое разное

с блокировкой изменений

не амазон :)

Зачем? Это усложняет api.

Чем усложняет? Какая разница где указывать "тип задачи", в параметрах или в URL?. Указывая в URL имя "специализированного" воркера хотя бы делаешь разделение логики и не придётся в документации писать "а вот если этот параметр "такой", то все остальные параметры должны быть вот такими". Плюс использование URL избавляет от самопального роутинга на стороне сервера. Использование единого URL - всё равно что в коде сделать одну мега-супер-функцию, которая в зависимости от значения аргументов может выполнять любую функциональность нужную в коде.

А на счёт локов которые предотвращают изменение ресурсов в момент работы над ними, то не совсем понятно - как это решается в неREST. Это ведь вообще не имеет к API сильного отношения. Эта проблема более фундаментальна и низкоуровневая и возникнет в независимости от того как организован API.

всем привет, какую либу посоветуете для валидации схемы json?

Сolander http://docs.pylonsproject.org/projects/colander/en/latest/

Сolander http://docs.pylonsproject.org/projects/colander/en/latest/

спасибо, оно там походу всякое разное валидировать умеет)

спасибо, оно там походу всякое разное валидировать умеет)

Валидирует оно в общем случае всегда некий питоновский объект (словарь или список). А вот что может десериализовать - это я не проверял, использовал только для JSON.

в принципе, мне оно только для json и нужно)

Судя по моим ощущениями и документации - оно само не занимается десериализацией сырого XML или HTML формы. На вход она принимает питонячий словарь или список, и просто приводит типы значаний к тем что указаны в схеме (например строку "10" из JSON может перевести в питонячий int - 10)

ребят, а есть чатик по сетям? добавьте плиз

ребят, а есть чатик по сетям? добавьте плиз

https://telegram.me/nag_public https://telegram.me/protelecom

https://telegram.me/nag_public https://telegram.me/protelecom

спасибо

Так, теперь чуть более фундаментальный вопрос) делаю абстрактную хрень в вакууме, но представляем, что это что-то важное. Хорошая ли это практика избавляться от исключений так, что каждая функция будет возвращать кортеж, где первый элемент - результат, а второй - ошибка, типа как в го принято, чтобы можно было возвращать множество ошибочных значений

Хотя начальное уточнение тут лишнее, вопрос вообще про такой подход)

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

В остальном обычно используют обычные исключения.

Надо просто ничего не перехватывать и всё повесить под супервизор, как в эрланге!

Если у тебя несколько ошибок, то они как правило однотипные - например ошибки валидаци разных полей в JSON. Просто все эти детали запихиваешь внутрь одного исклучения ValidationError

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

В питоне исключения вряд ли станут твоим ботлнеком

Оверхед на производительность идёт только в случае если исключение происходит - явно это очень редкая ситуация

вероятно, хотя я больше про идеологию) если это совсем не питоник вей, то хрен с ним

Главное не пихать исключения в самые ресурсозатратные и частые операции

Не использовать их как условия

А вот писать в стиле res, err = do_my_work() if err == ...: ... elif err == ...: .... Может быть несколько накладно

Это должно быть очень редкое событие

А то пихают исключения в рендер кадров и потом имеют 5 фпс

А вот писать в стиле res, err = do_my_work() if err == ...: ... elif err == ...: .... Может быть несколько накладно

вот я имел ввиду как раз что-то типа такого

вот я имел ввиду как раз что-то типа такого

Ну вот так в питоне не принято, я такого не видел.

В гошке так пишут от безысходности

Хорошо, спасибо) тогда не буду пока страдать всяким. Мне показалось это потенциально удобным, но хз, го не трогал, только чуть-чуть видел, после чего и появились такие мысли

В гошке так пишут от безысходности

Я не спец по go, но проведя параллель между go и питонячими асинхронными фреймворками могу понять почему у них нет исключений. В питонячей асинхронщине исключения тоже бесполезны. Их можно использовать только если try..except находится в той же функции что и вызывает исключение.

Как это противоречит тому, что я сказал?

Хотя в питоне всётаки исключения обрабатываются фреймворками и с ними можно немного работать :)

Надо просто ничего не перехватывать и всё повесить под супервизор, как в эрланге!

и аналог OTP тогда уж запилить хотя бы)

В гошке так пишут от безысходности

тащемта там можно сделать исключения через механизм паник Просто это никому не упёрлось - обрабатывать ошибки явно считатеся ТРУЪ

Или, может, кто знает более годный способ заскринить часть экрана?

Это не я если что

В питоне исключения вряд ли станут твоим ботлнеком

запросто.

Оверхед на производительность идёт только в случае если исключение происходит - явно это очень редкая ситуация

EAGAIN в errno и исключение OSError

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

потому я в горячих точках просто использую свои враперы к сисколлам вроде splice/sendfile

А на счёт локов которые предотвращают изменение ресурсов в момент работы над ними, то не совсем понятно - как это решается в неREST. Это ведь вообще не имеет к API сильного отношения. Эта проблема более фундаментальна и низкоуровневая и возникнет в независимости от того как организован API.

не в рест это решается... ну, например как в json-rpc. там передаётся вектор операций с аргументами.

не в рест это решается... ну, например как в json-rpc. там передаётся вектор операций с аргументами.

И как это мешает параллельному запросу изменить ресурс задействованый в операции?

И как это мешает параллельному запросу изменить ресурс задействованый в операции?

лок, либо можно эту пачку исполнять атомарно.

Ну вот, как я и сказал - сам способ организации API вообще никак волебным образом не решает эту задачу.

Хм, ну это можно реализовать добавив некий ресурс /worker, в который добавлять "задачки" по обработке пачки ресурсов. Статус этих задачек можно будет потом дёргать через /worker/<task_id>. Ну а на бекенде уже реализовать такую логику обработки задачек, что бы они не конфликтовали друг с другом.

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

Если есть какая то конкретная задача - то под неё делается конретный исполнитель.

Ну вот, как я и сказал - сам способ организации API вообще никак волебным образом не решает эту задачу.

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

Ничего волшебного REST не предлагает в этом плане

Никто нигде не говорил, что REST - это тупая обертка над CRUD с таблицами в базе данных. Никто не запрещал делать свои уникальные ресурсы, которые будет решать уникальные задачи.

Ничего волшебного REST не предлагает в этом плане

вот сидит клиент на мобильном инете(edge) и предлагаешь ему дергать всякие разные url и заниматься поллингом результатов?

А полинг тут причём? Как RPC от него избавляет?

А полинг тут причём? Как RPC от него избавляет?

ты выше писал.

Хм, ну это можно реализовать добавив некий ресурс /worker, в который добавлять "задачки" по обработке пачки ресурсов. Статус этих задачек можно будет потом дёргать через /worker/<task_id>. Ну а на бекенде уже реализовать такую логику обработки задачек, что бы они не конфликтовали друг с другом.

вот тут же ты сам пишешь, что "статус этих задачем можно будет потом дергать"

Ну да, я написал - ставим таску воркеру, и если нам это интересно - проверяем статус её выполнения. Если не интересно - не проверям. Если не хочится самому чекать статус - прикручиваем сбоку вебсокеты, пуши или ещё что то.

ну если так, то зачем тут вообще тогда рест?

А зачем тут RPC?

В чём разница то?

В чём разница то?

разница в rtt

А зачем тут RPC?

rpc - это вообще такая абстракция поверх message passing :)

ERROR: S client not available

У REST хотя бы есть свои плюшки в плане разработки, которые вытекают из унифицированного интерфейса. Легко автоматизировать генерацию документации, легко автоматизировать половину тестов API.

У REST хотя бы есть свои плюшки в плане разработки, которые вытекают из унифицированного интерфейса. Легко автоматизировать генерацию документации, легко автоматизировать половину тестов API.

чем он лучше grpc?

ну или json-rpc?

или если не нравится json, то можно взять другой сериализатор и сохранить конверцию?

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

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

ты просто представь, что пересылка запроса занимает 500ms

а запросов надо делать много и всяких разных.

Это ты про особености HTTP?

Ну тут не спорю - HTTP не очень эффективный транспорт для быстрой отправки большого числа сообщений. Хотя в HTTP/2 сделали уже гораздо лучше.

Это ты про особености HTTP?

ну, если мы говорим в рамках http 1.0, то там вообще на каждый запрос надо устанавливать коннект, что при rtt в 300-400ms означает 600-800ms на запрос.

можно REST на уровне философии как-то подружить с вебсокетами?

Ну тут не спорю - HTTP не очень эффективный транспорт для быстрой отправки большого числа сообщений. Хотя в HTTP/2 сделали уже гораздо лучше.

сделали, но это не золотая пуля.

Ну а в целом - REST это ведь про HTTP. Можно заюзать любой другой транспорт. Дело ведь в принципе работы с ресурсами, а не в протоколе.

Это ты про особености HTTP?

я скорее про сеть. пересылка запроса по сети может занимать существенное время и тут важно иметь максимально компактные запросы + возможность прозрачной агрегации их в пачку(чем-то похоже на алгоритм Нейгла)

Ну а в целом - REST это ведь про HTTP. Можно заюзать любой другой транспорт. Дело ведь в принципе работы с ресурсами, а не в протоколе.

это слоны в вакууме. в 100% случаев речь про http. можно сделать бенч, но я более чем уверен что rest по числу rps проиграет(хотя бы потому что сисколлов больше делать надо будет даже с keep-alive)

можно REST на уровне философии как-то подружить с вебсокетами?

Ну а почему бы и нет. Можно точно также посылать с клиента в веб-сокеты запросы к ресурам аналогичные POST, PUT, DELETE и др.

Ну а почему бы и нет. Можно точно также посылать с клиента в веб-сокеты запросы к ресурам аналогичные POST, PUT, DELETE и др.

но зачем?

т.е. можно даже сделать tcp/ip поверх вебсокетов, но зачем?

это слоны в вакууме. в 100% случаев речь про http. можно сделать бенч, но я более чем уверен что rest по числу rps проиграет(хотя бы потому что сисколлов больше делать надо будет даже с keep-alive)

Ну так ведь неREST штуки тоже работают поверх HTTP. За счёт чего у них то обходятся недостатки HTTP?

Ну так ведь неREST штуки тоже работают поверх HTTP. За счёт чего у них то обходятся недостатки HTTP?

единственный вариант - это посылать всё пачкой и ждать ответ на пачку.

интерес в вебсокетах именно в инициации события от сервера к клиенту

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

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

Ну да, это просто доп. механизм ни как не мешающий REST-у или ещё какому другому способу работать с ресурсами.

ну я про то, что это не укладывается в REST

ну я про то, что это не укладывается в REST

Это как бы просто не касается REST - это доп. механизм сбоку. Он ни как не влияет на использование REST или неREST. Особено если речь идёт про HTTP.

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

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

почему?

Ну хотя бы потому, что сами веб-сокеты вообще не предлагают каких то решений для этого. Придётся самому изобретать HTTP поверх веб-сокетов. Например что бы скачать файл с функцией докачки при обрыве связи (это как пример передачи больших объёмов данных)

Ну хотя бы потому, что сами веб-сокеты вообще не предлагают каких то решений для этого. Придётся самому изобретать HTTP поверх веб-сокетов. Например что бы скачать файл с функцией докачки при обрыве связи (это как пример передачи больших объёмов данных)

зачем хттп поверх вебсокетов?

вебсокеты - это про сообщения

Да, но человек спросивший про вебсокеты, видимо хотел вообще всё API через них пустить ?

Можно конечно, но по моему не имеет смысла