34. HTTP по-человечески
• HTTP = Протокол
• Описывает взаимодействие между двумя
компьютерами (клиентом и сервером)
• Построенное на базе сообщений:
– Запрос (Request)
– Ответ (Response)
• Каждое сообщение состоит из трех частей:
стартовая строка
[заголовок]
[тело]
35. HTTP по-человечески
• HTTP = Протокол
• Описывает взаимодействие между двумя
компьютерами (клиентом и сервером)
• Построенное на базе сообщений:
– Запрос (Request)
– Ответ (Response)
• Каждое сообщение состоит из трех частей:
стартовая строка
[заголовок]
[тело]
36. HTTP по-человечески
• HTTP = Протокол
• Описывает взаимодействие между двумя
компьютерами (клиентом и сервером)
• Построенное на базе сообщений:
– Запрос (Request)
– Ответ (Response)
• Каждое сообщение состоит из трех частей:
стартовая строка
[заголовок]
[тело]
37. HTTP по-человечески
• HTTP = Протокол
• Описывает взаимодействие между двумя
компьютерами (клиентом и сервером)
• Построенное на базе сообщений:
– Запрос (Request)
– Ответ (Response)
• Каждое сообщение состоит из трех частей:
стартовая строка
[заголовок]
[тело]
38. HTTP пример
• GET /index.html HTTP/1.1
Host: www.jug.lv
User-Agent: Mozilla/5.0
Accept: text/html
Connection: close
• HTTP/1.0 200 OK
Server: nginx/0.6
Content-Language: en
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Connection: close
... <то что вы запрашивали> …
39. Ресурсы
• GET /index.html HTTP/1.1
Host: www.jug.lv
User-Agent: Mozilla/5.0
Accept: text/html
Connection: close
URI Uniform Resource Identifier —
единообразный идентификатор
ресурса.
40. Методы
• GET /index.html HTTP/1.1
Host: www.jug.lv
User-Agent: Mozilla/5.0
Accept: text/html
Connection: close
GET, POST, PUT, DELETE… - действие
41. Мета-информация
• GET /index.html HTTP/1.1
Host: www.jug.lv
User-Agent: Mozilla/5.0
Accept: text/html
Connection: close
дополнительная информация,
разясняающая что мы хотим
42. А что в ответе?
• HTTP/1.0 200 OK
Server: nginx/0.6
Content-Language: en
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Connection: close
... <то что вы запрашивали> …
43. А что в ответе?
• HTTP/1.0 200 OK
Server: nginx/0.6
Content-Language: en
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Connection: close
... <то что вы запрашивали> …
Response Code – 200 – Получилось
Ну и OK для тех кто не понял
44. А что в ответе?
• HTTP/1.0 200 OK
Server: nginx/0.6
Content-Language: en
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Connection: close
... <то что вы запрашивали> …
дополнительная информация,
разясняающая что мы получили
45. А что в ответе?
• HTTP/1.0 200 OK
Server: nginx/0.6
Content-Language: en
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Connection: close
... <то что вы запрашивали> …
Ну и само представление
47. HTTP
• Все что надо в одном флаконе
• Cоздавался как каноническая
реализация REST-принципов
48. HTTP
• Все что надо в одном флаконе
• Cоздавался как каноническая
реализация REST-принципов
и цели этой достиг.
49. HTTP для REST систем
• это ВСЕ:
хлеб, масло и колбаса сверху.
50. HTTP для REST систем
• Или более формально:
и транспорт,
и метаданные,
и сервис.
51. HTTP в REST
• Для доступа к ресурсу используется
небольшое количество методов HTTP
• GET, PUT, DELETE, POST и др.
(!) в соответствии с их изначальным
смыслом
52. HTTP в REST
• Для доступа к ресурсу используется
небольшое количество методов HTTP
• Для передачи метаданных
используются HTTP-заголовки
53. HTTP в REST
• Для доступа к ресурсу используется
небольшое количество методов HTTP
• Для передачи метаданных
используются HTTP-заголовки
• Кеширование во всех видах
обеспечивает HTTP
54. HTTP в REST
• Для доступа к ресурсу используется
небольшое количество методов HTTP
• Для передачи метаданных
используются HTTP-заголовки
• Кеширование во всех видах
обеспечивает HTTP
• Проксирование — HTTP
55. HTTP в REST
• Для доступа к ресурсу используется
небольшое количество методов HTTP
• Для передачи метаданных
используются HTTP-заголовки
• Кеширование во всех видах
обеспечивает HTTP
• Проксирование — HTTP
• Авторизация — тоже через HTTP
56. HTTP в REST
• Для доступа к ресурсу используется
небольшое количество методов HTTP
• Для передачи метаданных
используются HTTP-заголовки
• Кеширование во всех видах
обеспечивает HTTP
• Проксирование — HTTP
• Авторизация — тоже через HTTP
57. REST
• Ключевые понятия:
– Resource (Ресурс)
– Representation (Представление)
– State (Состояние)
– Transfer (Перенос состояния)
58. Первоисточник
• Roy Thomas Fielding
• 2000 год
• REST
– REpresentational
– State
– Transfer
59. Что предлагает REST
• «Все» есть ресурсы
• Каждый ресурс уникален
• Отказаться от использования
одинаковых URI для разных ресурсов
61. Что предлагает REST
• Каждый ресурс может иметь
различные представления
• Для человека – HTML,…
• Для “enterprise” – XML,…
• Для JavaScript – JSON,…
64. Rest in Action
• Примеры ресурсов
• Ресурс-объекта
/jug/2012-04/presentation/rest Accepts=PPT
• Ресурс как запрос
/jug/search?author=Denis
• Ресурс действие
/jug/author?from=5&size=2
65. Rest in Action
• Примеры операций
• Список авторов
GET /jug/author
• Добавить автора
POST /jug/author?name=Denis
• Удалить автора
?
66. Rest in Action
• Примеры операций
• Список авторов
GET /jug/author
• Добавить автора
POST /jug/author/Denis
• Удалить автора
DELETE /jug/author/Denis
71. REST in Action
Request: Как создать нового USER’a?
POST /user HTTP/1.1
Content-Length: 27
Content-Type: application/json
{“name”:”DMITRY”, “email”:”dmitry@jug.lv”}
Response: HTTP/1.0 200 OK
73. REST in Action
Request: Как изменить USER’a?
PUT /user/DENIS HTTP/1.1
Content-Length: 27
Content-Type: application/json
{“name”:”DENIS”, “email”:”denis@gmail.com”}
Response: HTTP/1.0 200 OK
77. REST in Action
Request: Как удалить USER’a?
DELETE /user/DENIS HTTP/1.1
Response:
HTTP/1.0 404 Not found
78. REST in Action
Request: Список пользователей?
GET /user HTTP/1.1
Accept: application/json
HTTP/1.0 200 OK
Response: Content-Language: en
Content-Type: application/json; charset=utf-8
Content-Length: 1234
Connection: close
{
“user”:{“name”:”DMITRY”, “email”: “dmitry@jug.lv”}
}
79. REST сам по себе "рассчитан"
только на то, чтобы система
была простой, понятной и
масштабируемой
Hinweis der Redaktion
Что это - очередная “уловка консультантов от enterprise” ? А нам это нужно ? Не пытаются ли нас «опять» увести в дебри «enterprise»?
Как обычно бывает в мире “стандартов” и “денег” Там где речь идет о “больших” деньгах к вам приезжают и продают “готовые” и “работающие” и сказочные решение за “дофига” реальных денег.
Я думаю что каждому приходилось слышать - “Мы купили СУПЕР-ПУРЕР-ПАРАВОЗ который заменит все ваши самописанные велосипеды! Вот он. Теперь вы должны его запустить”
Как часто мы видели как СУПЕР-МЕГА-ПАРАВОЗ превращается в МЕГА-ПШИК? Вы обращали внимание как мы с готовностью тратим большое количество времени, что бы утвердить и начать использовать, что-то, что очень похоже на другую систему, которая уже потерпела фиаско. Мы используем HTTP, но только потому, что этот протокол позволяет нам меньше взаимодействовать с нашей сетью и специалистами по безопасности. Мы подменяем простоту яркими штучками и мастерами настройки , звенелками, гуделками и трещалками. велосипед - ? хотим лучше и больше - ? большой веловипед
Случалось-ли вам ходить в “программистский АД”? Вы обращали внимание, что обочины этой дороги, завалены именно такими “супер-модными-революционными” ВЕЛОСИПЕДАМИ со всеми их свистелками-генерилками-сериализаторами-валидаторами-биндерами-визардами.
Попробуйте убедить меня еще раз в том, что &quot;клац-клац — и готово&quot; - это то, что мне нужно. Ха-Ха-Ха
Так чем нам может помочь REST?
Так чем нам может помочь REST?
Ваши демоны не падут от одного слова REST
Следовательно его надо как минимум ПОНЯТЬ. А то зачастую можно услышать снова: &quot;Я Пастернака не читал, но осуждаю...&quot;
REST предлагает не мудрить а использовать те средства которые есть в веб с начала времён. REST предлагает не плодить новые сущности а использовать то что уже давно прекрасно работает.
REST предлагает не мудрить а использовать те средства которые есть в веб с начала времён. REST предлагает не плодить новые сущности а использовать то что уже давно прекрасно работает.
HTTP строился из принципов REST Или же REST описал то, что заложенно в HTTP ?
Ничего сложного тут нет: стартовая строка запроса, которая выглядит так: METHOD URI HTTP/ VERSION , где METHOD — это как раз метод HTTP-запроса, URI — идентификатор ресурса, VERSION — версия протокола (на данный момент актуальна версия 1.1). Заголовки — это набор пар имя: значение В заголовках передается различная служебная информация: кодировка сообщения, название и версия браузера, адрес, с которого пришел клиент (Referrer) и так далее. Тело сообщения — это, собственно, передаваемые данные. Все достаточно просто :)
Resource - > Что нам надо? Какой обьект(сущность) мы хотим «потрогать»
в соответствии с их изначальным смыслом
в соответствии с их изначальным смыслом
Кэширование на стороне клиента (в браузере, в кэше приложения) Кэширование на уровне intermediaries (прокси) Полное использование архитектуры Web Как итог: меньше запросов/трафика на ваши сервера Надо лишь выдавать корректные HTTP-заголовки: Last-Modified; ETag; Expires; Cache-Control
в соответствии с их изначальным смыслом
в соответствии с их изначальным смыслом
в соответствии с их изначальным смыслом
REST (REpresentational State Transfer) — это термин был введен в 2000-м году Роем Филдингом (Roy Fielding) — «Designing the Web Architecture: Problems and Insights» - его докторская диссертация одним из разработчиков протокола HTTP в качестве названия группы принципов построения веб-приложений. Вообще REST охватывает более широкую область, нежели HTTP — его можно применять и в других сетях с другими протоколами. REST описывает принципы взаимодействия клиента и сервера, основанные на понятиях «ресурса» и «глагола» (можно понимать их как подлежащее и сказуемое). В случае HTTP ресурс определяется своим URI, а глагол — это HTTP-метод.
URIs вместо одной точки входа (RPC) Нет нужды анализировать тело запроса, чтобы понять что с ним делать Балансируется просто по кускам URI: – /users/ - на backends_1 – /orders/ - на backends_2 – /users/[ID]/profile – sharding на уровне [ID] В URI не обязательно должен быть смысл – но это часто удобно – в виде правил именования.