Александр Нестеров

Любой VPS/VDS сервер.

Собственно, непонятно зачем делать 4 отдельных запроса.
В идеале - делайте один запрос на сервер (в текущем примере - на /cart/deleteOneAjax/<id>). А сервер сам должен обработать все необходимые изменения и вернуть новый вариант корзины.

1.Идете на Бинанс, находите раздел посвященный API и изучаете
2.Настраиваете авторизацию, если нужно
2.Качаете requests, читаете доки к ней
3.Подключаетесь к API с использованием соответствующих данных для авторизации (если они нужны)
4.Шлете запросы.

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

Ну, в теории можно... Из вариантов: react native и pwa для фронта, а бек делать и размещать как обычно (только не на хостинг, а на ноут)

Нужно ли для этого становится бэкенд-разработчиком

Ну, если вас/клиента устроит статический сайт, то текст/медиаконтент можно вставить напрямую в вёрстку или использовать конструктор сайтов.
Либо использовать moodle (движок для курсов). Сильно не тестил, но вроде достаточно просто "развернуть" на хостинге а дальше настраивать в админке.
Если хотите свое и "по-серьезному" то да, бекэнд нужен. Знаете java - spring boot в помощь.
Сколько займет зависит только от того, насколько хорошо знаете java и сколько времени готовы уделить обучению.

поставил Strapi и теперь не могу понять, как мне связать ее с фронтом?

Где он хранится, как вывести его на PHP сайт?

Момент номер 1: А с каких пор PHP стал фронтом? Тот факт, что вы вставили в [filename].php кусок html-разметки, не делает язык фронтэндом.
Момент номер 2: Допустим, вы все-таки понимаете разницу между серверной частью сайта и клиентской и действительно хотите передавать данные сперва в PHP. В таком случае возникает вопрос - а нафига? Вся логика (ну или как минимум - основная), связанная с обработкой данных уже реализована в Strapi, с "той стороны" нужно "тупо" отправлять и принимать данные (очень упрощенно, но в текущий момент это не важно). И в 2022-м году для этого достаточно JS, крутящегося в браузере.
(Нет, безусловно, существуют сложные сервисы, передающие данные между разными "независимыми" серверами (см. микросервисы), но что-то мне подсказывает, что это не ваш случай)

Какие-то rest api, фреймворки

Ну так почитайте про эти "какие-то". Как минимум, rest api - вещь максимально конкретная.
Если говорить максимально просто то выглядит это так:

1. Клиентская часть (js в браузере/полноценное приложение на пк/смартфоне, либо другой сервер, как уже писал выше) посылает get/post/...-запрос по определенному адресу.
   
2. Серверная часть принимает этот запрос, выделяет данные пришедшие в теле запроса (которые есть не всегда)
   
3. Серверная часть делает какую-то магию (выборку данных из бд, в т.ч. и на основе полученных от клиента данных, или как-то обрабатывает их).
   
4. Серверная часть отправляет готовые данные в одном из форматов (зачастую json, но иногда могут быть и другие, по типу xml).
   
5. Клиентская часть получает их и отображает их (с применением какой-то логики или без)
   
   

Это если рассматривать максимально примитивный вариант. На деле в этом процессе задействовано больше слоев по типу авторизации.

Если говорить в общем, для начала - рассмотрите существующие сайты и то, какие данные им нужны для заказа и что они показывают в итоге. Потом распишите, какие данные будут собираться для оформления заказа у вас и что будет указано в чеке.

Ну, как вариант - что-то вроде:
"разработка библиотеки компонентов для интернет-магазинов / торговых площадок" (аля bootstrap для магазинов)

Копаюсь в исходниках сайтов.

А смысл? Не лучше ли сперва почитать основы? В них подробно описываются подобные вещи.

site.ru&id=12

Это - параметр URL, хотя и неправильно записанный.
Правильно будет:
example.com/addres?key=value&?key2=value2

site.ru#profile12

Это похоже на якоря
Гугл выдаст 100500 статей по ним

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

А загуглить готовые решения (гугл легко выдаст с десяток вариантов на запрос "цмс для магазина)?
Но как вариант:

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

На моей памяти - ни один из дипломов с потока так и не ушел в продакшен (как в технаре, так и в универе) но если условием сдачи является внедрение (что маловероятно, кмк), то выбирать скорее всего не придется - находите какое-нибудь заведение, договариваетесь (думаю, можно даже фиктивно) и пилите систему для нее.
Если нет - пишите, что душе угодно.
Конкретно по темам в голову приходит автоматизированная система для экспедитора (условный сайт/клиент/приложение для магазинов, с помощью которого будут оформляться заявки, мобильное приложение для самого экспедитора со списком заявок и прочими прелестями, дополнительно могущее в отчетность (поставлено за день/неделю/месяц... поставлено для магазинов а/б/..);

На heroku и иже с ними обычно заливают проекты с серверной частью или программы косвенно связанные с вебом. У меня, например, там с дипломки висит сайт на Django (фреймворк на питоне) и дискорд-бот.
Github pages же предназначен для "статичных" сайтов - одностраничников\лендингов\состоящих из пары страниц, с небольшим количеством JS.

Насколько я понял, вам нужна СДО - система дистанционного обучения.
По личному опыту могу посоветовать Moodle. Насчет оптаты - не знаю, т.к. он у нас для заданий в универе настроен, но по идее должны быть плагины. Если нет - присмотритесь к другим.