Еще как будет: www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.1
HTTP протокол не запрещает использовать произвольные имена методов.
Вы, мне кажеться, мешаете мух с котлетами. Протокол позволяет передать набор разных штук вроде метода, url, заголовков и тела в приложение.
Промежуточные узлы должны уметь поддерживать такую передачу.
То есть формальное описание HTTP — оно для разработчиков клиентского движка, разработчиков прокси и разработчиков веб-серверов.
А что вы туда положите — уже ваше дело. Не надо заявлять о проблеме того, что «метадананные становяться обязательными» — это не проблема уровня протокола. Клиентская библотека сможет закодировать новый заголовок? Прокси сможет его передать? Сервер сможет его прочитать и передать приложению? Если да, отлично, протокол справился.
HTTP не регулирует ограничения того, что клиент передает в запросах и что он расчитывает получить от сервера.
Возвращаясь к нашему примеру, это вовсе не HTTP-протокол обяжет вас передавать во втором заголовке путь назначения для MOVE. Вам это нужно будет сделать, что бы вас поняло приложение, которму вы шлете запрос. А протокольная часть она что, она закодирует ваш запрос без заголовка, и потом раскодирует ответ с ошибкой от приложения, которое не нашло заголовка и послало вам 400 Bad request.
Кстати, в SIP коды состояний такие же как и в HTTP — числовые. Только помимо 1xx-5xx(семантика которых совпадает с HTTP) есть еще 6xx.
ACK — это запрос(как PUT и GET), со спец. семантикой, а не код состояния. Но SIP это вобщем-то совсем не HTTP-протокол, просто он внешне похож.
Да блин, вы написали столько текста, а лучше бы постарались внимательнее понять что я хотел сказать.
Ясен пень, что в HTTP нет состояния, никто не предлагает делать цепочку в стиле SORT->GET
Ну представьте что у вас есть каталог, в котором элементы физически упорядочены и SORT скажем меняет их порядок, не на уровне представления, а на уровне хранения. Ну скажем этот порядок имеет значение потому что эти элементы потом в таком порядке кем-то обрабатываются. (т.е. что-то вроде того что делает CLUSTER в постгресе)
Ну или забейте на SORT, если он вас так смущает. Представьте что вам нужен метод REPLACE для атомарной замены. Или TRANSFER для перевода ресурсов из счета А в счет Б. Помоему, отличный кандидат на звание «метода» в нашем API.
Про то что «не все клиенты поддерижвают произвольные методы». Это правда, никто этот факт не игнорирует, просто нравится строить API из предположения что большинство клиентов все-таки нормальные, а все остальные смогут заюзать какой нибудь workaround, скажем можно продублировать логику так, что все запосы можно сделать с помощью POST с глаголом, размещенным в теле запроса или заголовке.
Если честно я читаю, и вообще не понимаю о чем речь.
Метод — это просто строчка. Прокси, веб сервер и прочий middleware просто прокидывает эту строчку в приложение. А приложение уже наделяет эту стрчоку семантикой.
В этом смысле, не вижу проблем с методом SORT, сомневаюсь, что есть хоть какой-то вид софта, который заблокирует запрос, начинающийся с SORT только потому, что такого метода в RFC не описано
К слову, наличие или отсутствие тела на уровне парсера или прокси определяется по заголовкам Content-Length, Content-Type и Content-Disposition, а не по названию метода, так что даже для этих частей название не имеет значения.
Это же ООП получается — есть интерфейс «сущность», с четырьмя методами(POST, GET, PUT, DELETE) и дальше вы просто приводите список имплементаций интерфейса.(dog, cat, carrot)
А кейс с newDog/deleteCat похож на c-like API
То есть через пол секунды)
Вобщем идея вот какая. Когда в изначальном эксперементе говорят «загорится через секунду», не имеется ввиду что она через секунду «воспылает ярким пламенем».
Через секунду после включения рубильника напряженность поля около лампы начнет меняться.
Ну а производная напряженности возможно и будет в два раза меньше.
Ну, честно говоря, тогда в условие стоит добавить, что числа вещественные. Иначе, по дефолту кажеться, что они целые(ну хотя бы потому что до этого речь шла про salary), и решение с логарифмами отсеивается
Круто, но тут будут проблемы с точностью. А если в условии числа целые, то и ответ, наверняка, ожидается точный.
По сабжу, правильное решение — это самописная агрегатная функция.
Но авторы вероятно хотели увидеть решенние с иерархическим запросом(я угадал?)
Сейчас, для преодоления 72 000 км (туда-обратно), у сигнала уходит больше 500 миллисекунд
Занудство, но, на туда-обратно сигналу требуется 250 мс. 500мс требуется для сигнала компьютер1-спутник-компьютер2-спутник-компьютер1(144 000 км, скорость света — 300 000 км/c). То есть, именно такой будет ping от одной наземной станции до другой, тоже наземной через спутник.
Есть такая профессия даже — делать так, что бы 100 дураков объеденившись заменили умного человека…
Так что количественное описание вполне себе самодостаточное.
Ну че сказать, плохо дело.
Это все равно что покупать машину по рекламе.
Зачем слушать мои мысли? Результат моей работы вот он, а чего не видно, того и нет. Какой смысл выслушивать от человека какой он молодец, что на протяжении года сортировал имена переменных в классе по алфавиту, если никому от этого ни холодно, ни жарко?
Вы хотите сказать, что менеджер не сможет оценить хорошо человек работает или нет, без красочного рассказа?
То есть я просто не понимаю, вот люди год вместе работали, а потом хопа, и рассказывают друг другу, кто чем занимался?
Гм, я так расчитывал что хоть в одном более-менее общеизвестном формате появяться back reference.(возможность ссылаться на другой объект внутри документа)
Но в статье про них не упоминается, значит и тут их нет?
Эмм, что именно вы скомпилировали?
Никаких идеалогических соображений.
Просто rethrow вызывается в конструкции вида
} catch(Throwable t) {
retrhow(t);
}
И ваш тип T выводится как Throwable.
А значит у вызывающего метода должен быть Throwable в списке проверяемых исключений.
Еще как будет: www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.1
HTTP протокол не запрещает использовать произвольные имена методов.
Вы, мне кажеться, мешаете мух с котлетами. Протокол позволяет передать набор разных штук вроде метода, url, заголовков и тела в приложение.
Промежуточные узлы должны уметь поддерживать такую передачу.
То есть формальное описание HTTP — оно для разработчиков клиентского движка, разработчиков прокси и разработчиков веб-серверов.
А что вы туда положите — уже ваше дело. Не надо заявлять о проблеме того, что «метадананные становяться обязательными» — это не проблема уровня протокола. Клиентская библотека сможет закодировать новый заголовок? Прокси сможет его передать? Сервер сможет его прочитать и передать приложению? Если да, отлично, протокол справился.
HTTP не регулирует ограничения того, что клиент передает в запросах и что он расчитывает получить от сервера.
Возвращаясь к нашему примеру, это вовсе не HTTP-протокол обяжет вас передавать во втором заголовке путь назначения для MOVE. Вам это нужно будет сделать, что бы вас поняло приложение, которму вы шлете запрос. А протокольная часть она что, она закодирует ваш запрос без заголовка, и потом раскодирует ответ с ошибкой от приложения, которое не нашло заголовка и послало вам 400 Bad request.
Кстати, в SIP коды состояний такие же как и в HTTP — числовые. Только помимо 1xx-5xx(семантика которых совпадает с HTTP) есть еще 6xx.
ACK — это запрос(как PUT и GET), со спец. семантикой, а не код состояния. Но SIP это вобщем-то совсем не HTTP-протокол, просто он внешне похож.
Ясен пень, что в HTTP нет состояния, никто не предлагает делать цепочку в стиле SORT->GET
Ну представьте что у вас есть каталог, в котором элементы физически упорядочены и SORT скажем меняет их порядок, не на уровне представления, а на уровне хранения. Ну скажем этот порядок имеет значение потому что эти элементы потом в таком порядке кем-то обрабатываются. (т.е. что-то вроде того что делает CLUSTER в постгресе)
Ну или забейте на SORT, если он вас так смущает. Представьте что вам нужен метод REPLACE для атомарной замены. Или TRANSFER для перевода ресурсов из счета А в счет Б. Помоему, отличный кандидат на звание «метода» в нашем API.
Про то что «не все клиенты поддерижвают произвольные методы». Это правда, никто этот факт не игнорирует, просто нравится строить API из предположения что большинство клиентов все-таки нормальные, а все остальные смогут заюзать какой нибудь workaround, скажем можно продублировать логику так, что все запосы можно сделать с помощью POST с глаголом, размещенным в теле запроса или заголовке.
Метод — это просто строчка. Прокси, веб сервер и прочий middleware просто прокидывает эту строчку в приложение. А приложение уже наделяет эту стрчоку семантикой.
В этом смысле, не вижу проблем с методом SORT, сомневаюсь, что есть хоть какой-то вид софта, который заблокирует запрос, начинающийся с SORT только потому, что такого метода в RFC не описано
К слову, наличие или отсутствие тела на уровне парсера или прокси определяется по заголовкам Content-Length, Content-Type и Content-Disposition, а не по названию метода, так что даже для этих частей название не имеет значения.
А кейс с newDog/deleteCat похож на c-like API
Вобщем идея вот какая. Когда в изначальном эксперементе говорят «загорится через секунду», не имеется ввиду что она через секунду «воспылает ярким пламенем».
Через секунду после включения рубильника напряженность поля около лампы начнет меняться.
Ну а производная напряженности возможно и будет в два раза меньше.
Оффтопик, но на эту тему есть замечательная песня Blame Canada
По сабжу, правильное решение — это самописная агрегатная функция.
Но авторы вероятно хотели увидеть решенние с иерархическим запросом(я угадал?)
Занудство, но, на туда-обратно сигналу требуется 250 мс. 500мс требуется для сигнала компьютер1-спутник-компьютер2-спутник-компьютер1(144 000 км, скорость света — 300 000 км/c). То есть, именно такой будет ping от одной наземной станции до другой, тоже наземной через спутник.
Так что количественное описание вполне себе самодостаточное.
Это все равно что покупать машину по рекламе.
Зачем слушать мои мысли? Результат моей работы вот он, а чего не видно, того и нет. Какой смысл выслушивать от человека какой он молодец, что на протяжении года сортировал имена переменных в классе по алфавиту, если никому от этого ни холодно, ни жарко?
То есть я просто не понимаю, вот люди год вместе работали, а потом хопа, и рассказывают друг другу, кто чем занимался?
Но в статье про них не упоминается, значит и тут их нет?
2. Эмм, я не хочу их обрабатывать в этом коде, я хочу пробросить их наверх. И хочу это сделать с минимальной головной болью.
catch(MyException1 e) {
throw rethrowChecked(e);
} catch(MyException2 e) {
throw rethrowChecked(e);
} catch(Throwable t) {
throw rethrowOthers(t);
}
?
Ну так короче вызвать
catch(Throwable t) {
throw rethrowOthers(t, MyException1.class, MyException2.class);
}
Никаких идеалогических соображений.
Просто rethrow вызывается в конструкции вида
} catch(Throwable t) {
retrhow(t);
}
И ваш тип T выводится как Throwable.
А значит у вызывающего метода должен быть Throwable в списке проверяемых исключений.