HTTP HEAD против производительности GET

Я настраиваю веб-службу REST, которая просто должна отвечать YES или NO, как можно быстрее.

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

Я полагаю, что я получаю поток тела, который не должен быть открытым/закрытым на моем сервере (около 1 миллисекунды?). Поскольку количество возвращаемых байтов очень низкое, я получаю какое-либо время в транспорте, в номере IP-пакета?

Заранее благодарим за ваш ответ!

Edit:

Чтобы дополнительно объяснить контекст:

  • У меня есть набор служб REST, выполняющих некоторые процессы, если они находятся в активном состоянии.
  • У меня есть еще одна служба REST, указывающая состояние всех этих первых служб.

Поскольку эта последняя услуга будет вызываться очень часто очень большим набором клиентов (один вызов ожидается каждые 5 мс), мне было интересно, может ли использование метода HEAD быть ценной оптимизацией? В тело ответа возвращается около 250 символов. Метод HEAD, по крайней мере, обеспечивает перенос этих 250 символов, но что это за последствия?

Я попытался сравнить разницу между этими двумя методами (HEAD vs. GET), работая в 1000 раз, но не вижу никакого усиления (< 1ms)...

ОТВЕТЫ

Ответ 1

RESTful URI должен представлять собой "ресурс" на сервере. Ресурсы часто хранятся как запись в базе данных или файл в файловой системе. Если ресурс невелик или медленный поиск на сервере, вы можете не видеть измеримое усиление, используя HEAD вместо GET. Возможно, извлечение метаданных происходит не быстрее, чем извлечение всего ресурса.

Вы можете реализовать оба варианта и сравнить их, чтобы узнать, что быстрее, но вместо того, чтобы микро-оптимизировать, я бы сосредоточился на разработке идеального интерфейса REST. Чистый REST API обычно более ценен в долгосрочной перспективе, чем kludgey API, который может быть или не быть быстрее. Я не обескураживаю использование HEAD, просто предлагая вам использовать его, только если это "правильный" дизайн.

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

Например, предположим, что вы хотите проверить, существует ли ресурс 123. A 200 означает "да", а 404 означает "нет":

HEAD /resources/123 HTTP/1.1
[...]

HTTP/1.1 404 Not Found
[...]

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

Ответ 2

Я нашел этот ответ, когда искал тот же вопрос, который задавал запрос. Я также нашел это на http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html:

Метод HEAD идентичен GET, за исключением того, что сервер НЕ ДОЛЖЕН возвращать тело сообщения в ответ. Метаинформация, содержащаяся в заголовках HTTP в ответ на запрос HEAD, ДОЛЖНА быть идентичной информации, отправленной в ответ на запрос GET. Этот метод может быть использован для получения метаинформации о сущности, подразумеваемой запросом, без передачи самого объекта-объекта. Этот метод часто используется для проверки гипертекстовых ссылок на достоверность, доступность и недавнюю модификацию.

Мне кажется, что правильный ответ на вопрос реквестера заключается в том, что он зависит от того, что представлено протоколом REST. Например, в моем конкретном случае мой протокол REST используется для извлечения довольно больших (как в более чем 10K) изображений. Если у меня есть большое количество таких ресурсов, которые проверяются на постоянной основе, и учитывая, что я использую заголовки запросов, тогда было бы целесообразно использовать запрос HEAD в соответствии с рекомендациями w3.org.

Ответ 3

Я категорически отвергаю такой подход.

Служба RESTful должна уважать семантику глаголов HTTP. Глагол GET предназначен для извлечения содержимого ресурса, в то время как HEAD-глагол не будет возвращать какой-либо контент и может использоваться, например, чтобы увидеть, изменился ли ресурс, узнать его размер или его тип, чтобы проверить, существует и т.д.

И помните: ранняя оптимизация - это корень всего зла.

Ответ 4

Ваша производительность вряд ли изменится с помощью запроса HEAD вместо запроса GET.

Кроме того, если вы хотите, чтобы он был REST-ful, и вы хотите получить данные, вы должны использовать запрос GET вместо запроса HEAD.

Ответ 5

Я не понимаю вашего беспокойства о том, что "поток тела открыт/закрыт". Тело ответа будет находиться в том же потоке, что и заголовки ответов HTTP, и НЕ будет создавать второе соединение (которое, кстати, больше в диапазоне 3-6 мс).

Это похоже на очень предвзятую попытку оптимизации на что-то, что просто не сделает существенной или даже измеримой разницы. Реальная разница - это соответствие с REST в целом, которое рекомендует использовать GET для получения данных.

Мой ответ НЕТ, используйте GET, если это имеет смысл, нет увеличения производительности с помощью HEAD.

Ответ 6

GET выбирает голову + тело, HEAD выбирает только голову. Не должно быть мнения, что это быстрее. Я не раскрыл вышеперечисленные ответы. Если вы ищете информацию META, чем для HEAD, которая предназначена для этой цели.

Ответ 7

Вы можете легко сделать небольшой тест, чтобы измерить производительность самостоятельно. Я думаю, что разница в производительности будет небрежной, потому что если вы возвращаете только "Y" или "N" в теле, то один дополнительный байт добавляется к уже открытому потоку.

Я бы тоже пошел с GET, потому что это более правильно. Вы не должны возвращать контент в заголовках HTTP, а только метаданные.