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

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

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

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

спасибо заранее для вашего ответа!

Edit:

чтобы объяснить дальнейший контекст:

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

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

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

75
get head http

7 ответов

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

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

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

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

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

HTTP/1.1 404 Not Found
[...]

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

118

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

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

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

29

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

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

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

10

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

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

7

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

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

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

3

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

3

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

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

0