Никто не мешает реализовать RPC-интерфейсы поверх HTTP, получая его семантику там, где она нужна. Более того, большинство из так называемых "RESTful API" именно так и делают — они представляют собой ориентированный на данные CRUD RPC, а термин REST используется сугубо как популярный баззворд.
Идея REST заключается строго в следующем: есть метаинформация запроса (http-коды, методы, URL, заголовки), давайте построим систему, в которой все агенты умеют их понимать и трактовать.
Центральная идея REST — Uniform Interface, неотъемлемой частью которого является т. н. HATEOAS: REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state. Филдинг подтверждает это в том числе в своем посте REST APIs must be hypertext-driven
В большинстве реализаций это так, но существуют исключения, которые отходят отходят от стандарта. В PostgreSQL NaN == NaN, и NaN больше чем любое число (больше, чем Infinity)
Конечно, bool(x) совсем не то же самое что x is True. Последний можно использовать для строгой проверки того, что x — в точности True, а не произвольный True-like объект с реализованным __bool__. Такая строгая проверка на идентичность None/True/False часто используется в сериализаторах, а is None встречается в обычном коде вообще везде.
Так, пользуясь RESTful-API разработчик вынужден собирать необходимые ему данные, загружая их из нескольких конечных точек, каждая из которых была создана для решения определённой задачи. Например, это такие конечные точки, как /users/_id и /tours/_id/location.
Я вечером откопал старый топик на mail.python.ru. Раньше диапазон этих "синглтонов" был [-1, 99], затем он был расширен до [-5, 100], но с введением bytes его еще раз расширили до [-5, 256] чтобы покрыть байт.
When a non-data attribute of an instance is referenced, the instance’s class is searched. If the name denotes a valid class attribute that is a function object, a method object is created by packing (pointers to) the instance object and the function object just found together in an abstract object: this is the method object. https://docs.python.org/3/tutorial/classes.html
class A:
def f1(self):
pass
def f2():
pass
a = A()
A.f1 = f2
print(a.f1) # <bound method f2 of <__main__.A object at 0x7f0fd200d610>>
Насколько я помню, «При доступе к атрибуту экземпляра Python создаст объект типа types.MethodType с полями func и self, если этот атрибут был найден в классе и является чем-то вызываемым».
Превращение функций в методы (bound methods, они же экземпляры MethodType) происходит еще на этапе создания объекта.
Никто никогда не проверяет значения через is, потому что is проверяет идентичность ссылок, а не значений. Он делает то же самое, что и id(x) == id(y). Через is делают быструю и надежную проверку на None, False, True и т. д.
import time
def rate_throttle(key, rate, d={}):
current = time.monotonic()
last = d.get(key, 0)
elapsed = current - last
sleep = 0
if rate > elapsed > 0:
sleep = rate - elapsed
d[key] = current + sleep
return sleep
for i in range(5):
# No more 5 requests per 1 second
time.sleep(rate_throttle('', 1/5))
print('Faster', i)
for i in range(5):
# No more 1 request per 2 second
time.sleep(rate_throttle('', 2/1))
print('Slower', i)
Температурный предел не указан, хотя вряд ли куртке под силу 30-градусный мороз, если только не высадить аккумулятор за полчаса. А он тут, к слову, приличного размера.
Мне кажется, что каталитическая грелка во внутреннем кармане куртки уделает этот термоповербанк как по цене, так и по эффективности
Я не думаю, что мое сообщение менялось с момента публикации. Если отбросить всю шелуху, то в мире победившего хайпа неверное представление некоторых людей о PUT является только вершиной айсберга ;)
И так, как напутал RFC, который определяет такую семантику для PUT (которая, между прочим, обуславливает идемпотентность этого метода)
The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload. https://tools.ietf.org/html/rfc7231#section-4.3.4
Я не понимаю этой апелляции к философии Unix. Фактически, любой браузер по определению идёт вразрез с принципом "программа должна делать одну вещь и делать её хорошо". Они его нарушают начиная с реализации различных веб-стандартов и технологий вроде WebRTC, WebGL, NaCl, HTML5/CSS которые по суммарной сложности превращают браузер в своего рода ОС и заканчивая vendor-specific фичами вроде синхронизации или email-клиента.
Никто не мешает реализовать RPC-интерфейсы поверх HTTP, получая его семантику там, где она нужна. Более того, большинство из так называемых "RESTful API" именно так и делают — они представляют собой ориентированный на данные CRUD RPC, а термин REST используется сугубо как популярный баззворд.
Центральная идея REST — Uniform Interface, неотъемлемой частью которого является т. н. HATEOAS: REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state. Филдинг подтверждает это в том числе в своем посте REST APIs must be hypertext-driven
Я подозреваю, что тут что-то неладное:
for (int i ; i < N; i++) {
;-)
Я нашел ответ на SO от бывшего члена комитета IEEE754.
В большинстве реализаций это так, но существуют исключения, которые отходят отходят от стандарта. В PostgreSQL NaN == NaN, и NaN больше чем любое число (больше, чем Infinity)
Еще один прикол NaN — он не равен ничему, даже самому себе
Мой вопрос с GraphQL никак не связан ;-)
Конечно,
bool(x)
совсем не то же самое чтоx is True
. Последний можно использовать для строгой проверки того, чтоx
— в точностиTrue
, а не произвольный True-like объект с реализованным__bool__
. Такая строгая проверка на идентичностьNone/True/False
часто используется в сериализаторах, аis None
встречается в обычном коде вообще везде.Чем именно это отличается от data-oriented RPC?
Я вечером откопал старый топик на mail.python.ru. Раньше диапазон этих "синглтонов" был [-1, 99], затем он был расширен до [-5, 100], но с введением
bytes
его еще раз расширили до [-5, 256] чтобы покрыть байт.https://bugs.python.org/issue1436243
https://hg.python.org/cpython/rev/4d1a15fc4748
https://github.com/deadsnakes/python2.4/search?q=NSMALLNEGINTS
https://github.com/deadsnakes/python2.5/search?q=NSMALLNEGINTS
Никакой магии нет, этот диапазон закешировали как наиболее часто используемый.
Хм, ты был прав. Документация пишет, что
Я почему-то был уверен, что это не так ;)
Превращение функций в методы (bound methods, они же экземпляры MethodType) происходит еще на этапе создания объекта.
Никто никогда не проверяет значения через
is
, потому чтоis
проверяет идентичность ссылок, а не значений. Он делает то же самое, что иid(x) == id(y)
. Черезis
делают быструю и надежную проверку на None, False, True и т. д.Между прочим, у Nginx есть встроенный лимитер запросов https://nginx.org/ru/docs/http/ngx_http_limit_req_module.html
А архитекторы роняют сеньоров
Мне кажется, что каталитическая грелка во внутреннем кармане куртки уделает этот термоповербанк как по цене, так и по эффективности
Я не думаю, что мое сообщение менялось с момента публикации. Если отбросить всю шелуху, то в мире победившего хайпа неверное представление некоторых людей о PUT является только вершиной айсберга ;)
Я напутал так, как напутал Филдинг, автор REST и один из архитекторов HTTP/1.1
И так, как напутал RFC, который определяет такую семантику для PUT (которая, между прочим, обуславливает идемпотентность этого метода)
Я не понимаю этой апелляции к философии Unix. Фактически, любой браузер по определению идёт вразрез с принципом "программа должна делать одну вещь и делать её хорошо". Они его нарушают начиная с реализации различных веб-стандартов и технологий вроде WebRTC, WebGL, NaCl, HTML5/CSS которые по суммарной сложности превращают браузер в своего рода ОС и заканчивая vendor-specific фичами вроде синхронизации или email-клиента.
Путает. Положа руку на сердце, до середины статьи не понимал, что еще за BP.