Общение с ЖЖ из скрипта по протоколу HTTP(S), ч.2: URL-адрес входа, интерфейсы
Начало: « Общение с ЖЖ из скрипта по протоколу HTTP(S), ч.1: документация».
Сосредоточимся на следующем фрагменте части III (Client/Server Protocol) раздела «LiveJournal Programming» документации:
https://stat.livejournal.com/doc/server/
ljp.csp.protocol.html <-- полное содержание этой части документации
ljp.csp.guide.html 23. Client/Server Protocol - Quick Reference
ljp.csp.auth.html 24. Authentication in the Client Server Protocol
ljp.csp.flat.protocol.html I. Flat Client/Server Protocol Reference
ljp.csp.xml-rpc.protocol.html II. XML-RPC Client/Server Protocol Reference
...
URL-адрес входа, интерфейсы
Как и в двух случаях, которые я упоминал в предыдущем посте в качестве примеров общения с веб-приложением по протоколу HTTP ( обращение к видеохостингу «YouTube», работа с веб-приложением «WordPress» по интерфейсу REST API), для взаимодействия с веб-приложением «LiveJournal» требуется знать специальный URL-адрес, по которому следует посылать HTTP-запрос.
Из документации я понял, что такой URL-адрес строится по следующему принципу:
"https://www.livejournal.com/" + "interface/" + "название интерфейса"
Вот примеры такого URL-адреса:
https://www.livejournal.com/interface/flat
https://www.livejournal.com/interface/xmlrpc
https://www.livejournal.com/interface/blogger
https://www.livejournal.com/interface/atom
Насколько я понял, функции веб-приложения «LiveJournal», к которым мы обращаемся через разные интерфейсы - одни и те же. Разные интерфейсы - это лишь разные способы обратиться к одним и тем же функциям веб-приложения «LiveJournal». Об этом сказано в документации:
Tip. Internally, all interfaces are just wrappers around the same functions. Don't worry too much about which one you use, as they accomplish the same thing.
Зачем тогда нужны несколько способов выполнения одного и того же? Как я понял, дополнительные интерфейсы были разработаны и стали популярны в других веб-приложениях. Программисты веб-приложения «LiveJournal» решили реализовать их, чтобы программистам, привыкшим к работе с другими интерфейсами, было удобно начать работу с веб-приложением «LiveJournal» по привычному для них интерфейсу.
Интерфейсы «flat» и «XML-RPC»
Я пока что буду рассматривать только интерфейсы «flat» и «xmlrpc» (вернее, «XML-RPC»), так как по ним в документации есть больше информации, чем по остальным интерфейсам.
1. Дословно слово «flat» в данном случае (у него есть несколько основных значений) по-русски означает «плоский», но подразумевается, насколько я понимаю, «самый простой». При этом интерфейсе в тело HTTP-запроса помещается строка в следующем формате:
параметр1=значение1&параметр2=значение2&параметрN=значениеN...
После получения HTTP-запроса веб-сервер присылает HTTP-ответ, который содержит строку с данными в следующем формате:
параметр1
значение1
параметр2
значение2
параметрN
значениеN
...
Думаю, понятно, что в приведенных выше схемах «параметр1», «значение1», «параметр2», «значение2» и так далее - это разные значения при отправке HTTP-запроса и получении HTTP-ответа.
При получении HTTP-ответа, как видно в блоке кода выше, названия параметров («параметр1», «параметр2» и так далее) и значения параметров («значение1», «значение2» и так далее) отделяются друг от друга символом новой строки, поэтому получился такой столбик.
Если описанное здесь всё еще остается непонятным, имейте в виду, что позже я продемонстрирую изложенное тут на практических примерах.
2. Интерфейс «XML-RPC» - это один из интерфейсов, придуманных в других проектах, вне веб-приложения «LiveJournal». В начале нулевых этот интерфейс был относительно популярен, поэтому, как я понимаю, программисты веб-приложения «LiveJournal» реализовали его для веб-приложения «LiveJournal». Сейчас, насколько я понимаю, более популярны интерфейсы вроде REST API, в которых веб-клиент получает от веб-сервера данные в формате JSON, а не в формате XML, как в интерфейсе «XML-RPC».
Статья в википедии по интерфейсу «XML-RPC»:
https://ru.wikipedia.org/wiki/XML-RPC
Сайт с примерами и спецификацией:
http://xmlrpc.com
По приведенным ссылкам можно узнать, как расшифровывается эта аббревиатура (не привожу эту расшифровку тут, так как не вижу в ней особого смысла), а также можно посмотреть, в каком виде формируются запросы и ответы. К этому моменту уже должно быть понятно, что по этому интерфейсу обмен данными идет тоже в текстовом виде, но текст подается и получается в формате XML. Если пока ничего непонятно, позже можно будет разобраться окончательно на практических примерах.
Продолжение следует.
Сосредоточимся на следующем фрагменте части III (Client/Server Protocol) раздела «LiveJournal Programming» документации:
https://stat.livejournal.com/doc/server/
ljp.csp.protocol.html <-- полное содержание этой части документации
ljp.csp.guide.html 23. Client/Server Protocol - Quick Reference
ljp.csp.auth.html 24. Authentication in the Client Server Protocol
ljp.csp.flat.protocol.html I. Flat Client/Server Protocol Reference
ljp.csp.xml-rpc.protocol.html II. XML-RPC Client/Server Protocol Reference
...
URL-адрес входа, интерфейсы
Как и в двух случаях, которые я упоминал в предыдущем посте в качестве примеров общения с веб-приложением по протоколу HTTP ( обращение к видеохостингу «YouTube», работа с веб-приложением «WordPress» по интерфейсу REST API), для взаимодействия с веб-приложением «LiveJournal» требуется знать специальный URL-адрес, по которому следует посылать HTTP-запрос.
Из документации я понял, что такой URL-адрес строится по следующему принципу:
"https://www.livejournal.com/" + "interface/" + "название интерфейса"
Вот примеры такого URL-адреса:
https://www.livejournal.com/interface/flat
https://www.livejournal.com/interface/xmlrpc
https://www.livejournal.com/interface/blogger
https://www.livejournal.com/interface/atom
Насколько я понял, функции веб-приложения «LiveJournal», к которым мы обращаемся через разные интерфейсы - одни и те же. Разные интерфейсы - это лишь разные способы обратиться к одним и тем же функциям веб-приложения «LiveJournal». Об этом сказано в документации:
Tip. Internally, all interfaces are just wrappers around the same functions. Don't worry too much about which one you use, as they accomplish the same thing.
Зачем тогда нужны несколько способов выполнения одного и того же? Как я понял, дополнительные интерфейсы были разработаны и стали популярны в других веб-приложениях. Программисты веб-приложения «LiveJournal» решили реализовать их, чтобы программистам, привыкшим к работе с другими интерфейсами, было удобно начать работу с веб-приложением «LiveJournal» по привычному для них интерфейсу.
Интерфейсы «flat» и «XML-RPC»
Я пока что буду рассматривать только интерфейсы «flat» и «xmlrpc» (вернее, «XML-RPC»), так как по ним в документации есть больше информации, чем по остальным интерфейсам.
1. Дословно слово «flat» в данном случае (у него есть несколько основных значений) по-русски означает «плоский», но подразумевается, насколько я понимаю, «самый простой». При этом интерфейсе в тело HTTP-запроса помещается строка в следующем формате:
параметр1=значение1&параметр2=значение2&параметрN=значениеN...
После получения HTTP-запроса веб-сервер присылает HTTP-ответ, который содержит строку с данными в следующем формате:
параметр1
значение1
параметр2
значение2
параметрN
значениеN
...
Думаю, понятно, что в приведенных выше схемах «параметр1», «значение1», «параметр2», «значение2» и так далее - это разные значения при отправке HTTP-запроса и получении HTTP-ответа.
При получении HTTP-ответа, как видно в блоке кода выше, названия параметров («параметр1», «параметр2» и так далее) и значения параметров («значение1», «значение2» и так далее) отделяются друг от друга символом новой строки, поэтому получился такой столбик.
Если описанное здесь всё еще остается непонятным, имейте в виду, что позже я продемонстрирую изложенное тут на практических примерах.
2. Интерфейс «XML-RPC» - это один из интерфейсов, придуманных в других проектах, вне веб-приложения «LiveJournal». В начале нулевых этот интерфейс был относительно популярен, поэтому, как я понимаю, программисты веб-приложения «LiveJournal» реализовали его для веб-приложения «LiveJournal». Сейчас, насколько я понимаю, более популярны интерфейсы вроде REST API, в которых веб-клиент получает от веб-сервера данные в формате JSON, а не в формате XML, как в интерфейсе «XML-RPC».
Статья в википедии по интерфейсу «XML-RPC»:
https://ru.wikipedia.org/wiki/XML-RPC
Сайт с примерами и спецификацией:
http://xmlrpc.com
По приведенным ссылкам можно узнать, как расшифровывается эта аббревиатура (не привожу эту расшифровку тут, так как не вижу в ней особого смысла), а также можно посмотреть, в каком виде формируются запросы и ответы. К этому моменту уже должно быть понятно, что по этому интерфейсу обмен данными идет тоже в текстовом виде, но текст подается и получается в формате XML. Если пока ничего непонятно, позже можно будет разобраться окончательно на практических примерах.
Продолжение следует.