Рой Филдинг является автором REST и соавтором HTTP. Это не "кто-то там", а авторитетный первоисточник по этому вопросу. Главный документ по REST уже написан, вам лишь нужно правильно ссылаться на него.
Все, что нужно знать о REST — он неотличим от HTTP.
Как это вообще понимать? Архитектурный стиль REST развивался параллельно с HTTP для того, чтобы выделить принципы, которые закладывались в основу HTTP. Это разные понятия.
Вдобавок, сам Филдинг пишет так:
A REST API should not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols, such as HTTP’s PATCH method or Link header field. Workarounds for broken implementations (such as those browsers stupid enough to believe that HTML defines HTTP’s method set) should be defined separately, or at least in appendices, with an expectation that the workaround will eventually be obsolete. [Failure here implies that the resource interfaces are object-specific, not generic.] https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Обязательных ограничений пять, а шестое — код по требованию — является опциональным. А в остальном совершенно солидарен с вами. Занятно, что сам Филдинг в своей диссертации указывал на любовь на любовь компьютерной индустрии к баззвордам:
Design-by-buzzword is a common occurrence. At least some of this behavior within the software industry is due to a lack of understanding of why a given set of architectural constraints is useful.
Держа руку на пульсе, главное не распыляться на скоротечную моду. Масса вещей в ИТ срослась с маркетингом и баззвордами, поэтому в погоне за новизной легко потерять лес за деревьями. Не верите? Спросите в каком-нибудь чате программистов, что такое REST, и 7 из 10 не смогут внятно ответить на этот вопрос.
Где-то в 2008 году Ларри Эллисон сказал следующее:
The computer industry is the only industry that is more fashion-driven than women's fashion. Maybe I'm an idiot, but I have no idea what anyone is talking about. What is it? It's complete gibberish. It's insane. When is this idiocy going to stop?
2008 год, господа)
Они предназначены для asyncio и отлично собираются в быстрый стек) Проблема асинхронности и кооперативной многозадачности для Питона в принципе уже решена — asyncio, gevent, stackless в PyPy, так что нужды в очередном асинхронном монофрейморке нет.
А моя реплика не в укор, а просто так. Эта ветка уже пустилась в пространные рассуждения)
Я вас удивлю, но этот пример переносим и не содержит UB. Значение x всегда будет 0. Выражение uint32_t x = -1 эквивалентно uint32_t x = UINT32_MAX, и этот способ используется для переносимого (!) заполнения всех битов в 1. С другой стороны, обратная операция (знаковое переполнение) уже является UB.
В свое время, после перехода на 3G, меня достали постоянные обрывы SSH сессий по таймауту. В конечном счете полностью снял проблему тремя строками в ~/.ssh/config:
В принципе, если загуглить "difference between data hiding and encapsulation", все станет на свои места. Инкапсуляция это объединение кода и данных, а сокрытие — защита от доступа извне. В С++ сокрытие и инкапсуляция эквивалентны, но для других языков это не так. В целом, это разные вещи, которые могут использоваться как вместе, так и независимо.
Всё в Си хорошо с инкапсуляцией, данные объединяются вместе с методами в одном модуле, и в заголовочном файле прописывается только публичный интерфейс.
Язык С не поддерживает явно модули, методы и инкапсуляцию. Ограничение области видимости статических функций в пределах одной единицы трансляции является сокрытием. Данные по-прежнему отделены от функций, и вам нужно вручную их совмещать. Более того, передача функции указателя на другой, несовместимый тип не является ошибкой.
Вообще, развита или не развита инкапсуляция зависит от конкретных разработчиков в конкретном проекте
Я не понимаю, о чем ты говоришь. Наличие развитых средств инкапсуляции в языке никоим образом не зависит от того, использует ли их конкретный разработчик.
В ООП мы ожидаем, что методы класса не закрыты от изменений переменных — членов этого класса. Однако мы ожидаем, что любой другой класс, включая подклассы, закрыты от изменений этих переменных. Это называется инкапсуляцией.
Это называется сокрытием, а не инкапсуляцией. В реализациях C# или C++ эти два понятия отождествляются, но если рассматривать ООП в общем, это не одно и то же. В Python развита инкапсуляция, но отсутствует сокрытие. В языке C с помощью Pimpl достигается полное сокрытие, но принципиально отсутствует инкапсуляция.
Для быстрого и энергоэффективного HTTP-сервера лучше взять uWSGI — он может без проблем смотреть "в мир" и обладает огромной гибкостью конфигурации, а в случае необходимости можно подключить один из WSGI-совместимых фреймворков. Его также можно подружить с aiohttp поверх uvloop — получите удобный и высококонкуррентный сервер на современных async/await, а uWSGI будет просто выступать мастер-процессом, контролирующим рабочие процессы.
Не нужно воспринимать мои посты как личностный выпад. Просто ваша статья противопоставляет RPC с HTTP и не содержит вещей, специфичных для REST.
Рой Филдинг является автором REST и соавтором HTTP. Это не "кто-то там", а авторитетный первоисточник по этому вопросу. Главный документ по REST уже написан, вам лишь нужно правильно ссылаться на него.
Как это вообще понимать? Архитектурный стиль REST развивался параллельно с HTTP для того, чтобы выделить принципы, которые закладывались в основу HTTP. Это разные понятия.
Вдобавок, сам Филдинг пишет так:
Обязательных ограничений пять, а шестое — код по требованию — является опциональным. А в остальном совершенно солидарен с вами. Занятно, что сам Филдинг в своей диссертации указывал на любовь на любовь компьютерной индустрии к баззвордам:
Держа руку на пульсе, главное не распыляться на скоротечную моду. Масса вещей в ИТ срослась с маркетингом и баззвордами, поэтому в погоне за новизной легко потерять лес за деревьями. Не верите? Спросите в каком-нибудь чате программистов, что такое REST, и 7 из 10 не смогут внятно ответить на этот вопрос.
Где-то в 2008 году Ларри Эллисон сказал следующее:
The computer industry is the only industry that is more fashion-driven than women's fashion. Maybe I'm an idiot, but I have no idea what anyone is talking about. What is it? It's complete gibberish. It's insane. When is this idiocy going to stop?
2008 год, господа)
Они предназначены для asyncio и отлично собираются в быстрый стек) Проблема асинхронности и кооперативной многозадачности для Питона в принципе уже решена — asyncio, gevent, stackless в PyPy, так что нужды в очередном асинхронном монофрейморке нет.
А моя реплика не в укор, а просто так. Эта ветка уже пустилась в пространные рассуждения)
https://github.com/MagicStack/uvloop
https://github.com/MagicStack/asyncpg
От комментариев двоякое чувство. Почему никого не беспокоит убитое время на игры и телесериалы?
Если быть крайне точным, эквивалентно
int x = sizeof(int) > SIZE_MAX;Я вас удивлю, но этот пример переносим и не содержит UB. Значение x всегда будет 0. Выражение
uint32_t x = -1эквивалентноuint32_t x = UINT32_MAX, и этот способ используется для переносимого (!) заполнения всех битов в 1. С другой стороны, обратная операция (знаковое переполнение) уже является UB.https://github.com/python/cpython/blob/v3.8.0/Modules/socketmodule.c#L2560
https://github.com/python/cpython/blob/v3.8.0/Python/ast_opt.c#L130
https://github.com/postgres/postgres/blob/REL_12_0/src/backend/utils/mmgr/dsa.c#L1234
Чему равен x? Даже на неявных преобразованиях базовых типов можно споткнуться.
В свое время, после перехода на 3G, меня достали постоянные обрывы SSH сессий по таймауту. В конечном счете полностью снял проблему тремя строками в ~/.ssh/config:
Раннее я пробовал пользоваться mosh, но, как оказалось, он не работает с прокруткой окна и не умеет монтировать удаленную ФС как sshfs. Пришлось выбросить.
PUT не поддерживается для HTML-форм.
https://developer.mozilla.org/ru/docs/Web/HTML/Element/form#attr-method
В принципе, если загуглить "difference between data hiding and encapsulation", все станет на свои места. Инкапсуляция это объединение кода и данных, а сокрытие — защита от доступа извне. В С++ сокрытие и инкапсуляция эквивалентны, но для других языков это не так. В целом, это разные вещи, которые могут использоваться как вместе, так и независимо.
Высокая связность в коде вообще не зависит от инкапсуляции, это проблема архитектуры в целом.
Язык С не поддерживает явно модули, методы и инкапсуляцию. Ограничение области видимости статических функций в пределах одной единицы трансляции является сокрытием. Данные по-прежнему отделены от функций, и вам нужно вручную их совмещать. Более того, передача функции указателя на другой, несовместимый тип не является ошибкой.
Я не понимаю, о чем ты говоришь. Наличие развитых средств инкапсуляции в языке никоим образом не зависит от того, использует ли их конкретный разработчик.
Это называется сокрытием, а не инкапсуляцией. В реализациях C# или C++ эти два понятия отождествляются, но если рассматривать ООП в общем, это не одно и то же. В Python развита инкапсуляция, но отсутствует сокрытие. В языке C с помощью Pimpl достигается полное сокрытие, но принципиально отсутствует инкапсуляция.
Что-то такое я уже читал https://habr.com/ru/company/cloud4y/blog/347444/
Для быстрого и энергоэффективного HTTP-сервера лучше взять uWSGI — он может без проблем смотреть "в мир" и обладает огромной гибкостью конфигурации, а в случае необходимости можно подключить один из WSGI-совместимых фреймворков. Его также можно подружить с aiohttp поверх uvloop — получите удобный и высококонкуррентный сервер на современных async/await, а uWSGI будет просто выступать мастер-процессом, контролирующим рабочие процессы.
Этот эффект называется эффектом Рингельмана, когда по мере роста численности группы падает эффективность ее отдельных членов.