al_gon

https://jsoup.org/

далёк от веб

HTML таки знать (хотябы понимать) придётся.

Формат неправильный. Нужно разделять пробелом:

# m h dom mon dow command
0 23 * * * /bin/java -jar /var/www/prg/programma.jar

Основной посыл использования RESTful API - применение основной идеи Паутины для взаимодействия автоматических агентов (приложений), а не только людей.
Основная идея Паутины - построение распределенной информационной системы путем публикации неких абстрактных ресурсов, выдачи им идентификаторов (в сегодняшнем вебе - иерархических), определения ряда простых и широко известных операций над ними, не зависящих от содержимого ресурса (те самые GET, POST, PUT и т.д.), и связывания этих ресурсов ссылками (это называется гипермедиа, и в частности, гипертекст, если речь идет о текстовой информации).
Как люди с появления Веба публикуют информацию в нем для потребления другими людьми, так и RESTful веб-сервисы публикуют иерархически структурированные ресурсы для потребления клиентами. Разница только в представлении - для людей это plaintext/HTML, для автоматических агентов - это JSON/XML/прочие форматы, которые удобно обрабатывать.
Таким образом, если вы хотите какую-то информацию опубликовать как RESTful API, вам необходимо представить ее как набор ресурсов, а все операции над этой информацией выразить через набор предопределенных операций. Фишка в том, что во многих задачах этих предпопределенных операций вполне достаточно, главное правильно определить ресурсы.
Важно понимать, что "ресурс" это обычно некоторая сущность, "существительное". Как правильно заметил Антон Жуков , ресурс /getItems хоть и может существовать в принципе, говорит о неудачно спроектированном API (действие представлено как ресурс).

Есть и другие подходы к архитектуре распределенных приложений, например архитектуры, основанные на RPC (удаленный вызов процедур). Информация в таких архитектурах также представлена в виде некоторого набора сущностей, однако операции над ними определяются конкретной задачей, и для каждой сущности будет свой набор. Это больше соотвествует классическому ООП-подходу. Таким образом, RESTful следует подходу много сущностей (ресурсов) - мало операций (и эти операции известны заранее), а RPC - немного сущностей, но много операций над ними.

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

Сама архитектура REST не привязана к конкретным технологиям и протоколам, но в реалиях современного Веб, построение RESTful API почти всегда подразумевает использование HTTP и каких-либо распространенных форматов представления ресурсов, например JSON, или, менее популярного сегодня, XML.

Смысл использования REST в том, что принципы, хорошо показавшие себя в "человеческом" веб и позволившие построить самую большую распределенную ИС, применяют и для "веба машин".

Ответ длинноват, но как короче объяснить, чтобы не исказить понимание, не представляю. Если что непонятно - спрашивайте.

Мне 16 лет.
Мотивация у самого меня большая. Еще с 6 лет понял, что мой путь это явно что-то в it-сфере, когда впервые сел за компьютер. Начинал пытаться программировать(если "хеллоу ворлд" можно назвать программированием) в 9 лет.
Всегда считал, что я что-нибудь такое создам неповторимое, того чего еще нет и буду много зарабатывать.
Да и сейчас так считаю :)
Когда занимаешься изучением программирования, никогда не думай что это бесполезно потому что реализовать себя в этой сфере можно очень круто. Так круто, что во многих других сферах ты этого сделать не сможешь.
Просто набирайся опыта, читай, изучай все новое и вскоре, если будешь упорным и знать того, что ты хочешь, ты определенно добьешься успеха.. Желаю удачи!

Я напишу в целом, т.к. это подойдет для любого языка

Алгоритм работы парсера довольно прост, и по большей части делится на 3и этапа:
1) Получить данные
2) Разобрать данные
3) Сохранить данные

1) Для того чтобы получить данные, надо изучить стек функций для работы с сетью. Можно гуглить по такому запросу "Как скачать веб-страницу" + твой ЯП (PHP, Java, Python и т.д.). Тут ты должен написать функцию которой на вход передашь url, а на выход получишь данные (html, json, xml и т.д.)

2) Разобрать данные можно либо с помощью готовых библиотек под нужный формат, либо с помощью регулярных выражений, либо с помощью строковых функций. Тут на помощь придет запрос "Строковые функции" + твой ЯП или "регулярные выражения" + твой ЯП. На этом этапе ты должен написать функцию, которой на вход поступают данные, а на выходе получаешь заранее утвержденную структуру.

3) Сохранять данные в необходимой структуре можно в файлы или в БД. Опять в гугл с запросом "Работа с бд " + твой ЯП, либо "Работа с файлами" + твой ЯП. Тут твоя задача написать функцию, на вход которой приходит заранее утвержденная структура, а на выходе ты получаешь результат "сохраненные данные"

Ну, собственно и всё. Идешь в гугл, изучаешь матчасть и пишешь парсер.

Если же тебя в большей степени интересуют алгоритмы разбора, тогда советую посмотреть код "калькуляторов" на твоем ЯП, погуглить можно по запросу "калькулятор со скобками", "Разбор и вычисление выражений". Это классическая задача, разбор твоего куска будет очень похож.

Объяснить суть полиморфизма "на пальцах" довольно просто. Представьте себе класс Телефон. Его спроектировал некто в далеких 80-х, и определил в нем метод набратьНомер(). А потом другой программист в 90-х отнаследовал от него класс МобильныйТелефон и перекрыл метод набратьНомер(), т.к. грубо говоря, в новом устройстве набор производится уже не импульсно, а тонально. А потом третий программист отнаследовал от него класс Смартфон. При этом он не стал трогать метод набратьНомер(), а просто добавил методы для нового функционала, типа определитьПоложениеПоGPS() и т.д.

Теперь представьте себе пользователя. Он родом из 80-х и понятия не имеет о тональном наборе и GPS... но если ему в руки дать любое из этих устройств, он сможет набрать номер и сделать звонок. Почему? Потому, что он умеет использовать метод набратьНомер(), и большего ему знать не нужно.

А теперь представьте другого пользователя, нашего современника. Он вырос в эпоху смартфонов... но если ему в руки дать старый телефонный аппарат, он тоже сможет сделать звонок, т.к., опять же, знает метод набратьНомер().

Применительно к ООП, пользователь - это переменная, содержащая ссылку на экземпляр класса. Ее тип (как она была объявлена) - это "набор знаний" о возможностях этого экземпляра. И т.к. Смартфон в своей основе является Телефон-ом, мы вполне можем дать его в руки гипотетическому пользователю из 80-х:
Телефон устройство = new Смартфон();
в результате чего он сможет сделать звонок:
устройство.набратьНомер("03");
А вот определить свое местоположение он не сможет, пока не узнает о существовании соотв. метода:

Смартфон усовершенствованноеУстройство = (Смартфон)устройство;

Это называется приведением типа. В данном примере у экземпляра класса уже был соотв. метод, но чтоб им воспользоваться, нужно сначала явно указать, что мы хотим рассматривать имеющееся у нас в руках устройство не как "простой" Телефон, а как Смартфон.

P.S. Кстати, в этом примере мы затронули не только полиморфизм, но и наследование, и инкапсуляцию (пользователя "снаружи" совершенно не интересует, как именно производится набор номера - тонально, импульсно или еще как-то иначе)... так сказать, все три кита ООП в одном флаконе. И только так вообще имеет смысл рассматривать эти принципы, т.к. они по сути неотделимы друг от друга, как Отец, Сын и Святой Дух в Христианстве или же длина, ширина и высота в трехмерном пространстве :) Если это понять, ООП становится совершенно простой и естественной парадигмой программирования.

Попробуйте doc.select("div.page-list-item.container");