galliard

Твой репозиторий и есть коллекция. Можешь просто добавить лимит и офсет к getList().

Никак. Разработка NetBeans сильно отстает от разработки php. К моменту выпуска поддержки php 7.1 уже php 8 выйдет.

fastcgi - что-то вроде сервера, который слушает определенный сокет. Он держит пул процессов (воркеров), которые принимают запросы, обрабатывают, возвращают ответ и ждут дальше запроса.

Вот в этой фразе замени fastcgi на php-fpm и будет правильно. А fastcgi - это технология обработки запроса, по которой каждый воркер крутится в бесконечном цикле, обрабатывая в каждой своей итерации по одному запросу.

Ничего их перечисленного в контроллере не делается. Вся бизнес-логика должна располагаться в сервисе. Контроллер только принимает http-запрос, валидирует его, и если он валиден - отправляет данные в сервис.

Похожесть или не похожесть - понятие очень субъективное, кто-то скажет, что почти одно и то же, кто-то что принципиально разные. Но это лишь особенности личного восприятия.

В целом же - любая практика в программировании будет способствовать твоему развитию.

Например, слышал что си это процедурный язык, и в пхп есть возможность ООП. И если я познаю все эти принципы ООП, не будут ли они мне потом не давать нормально позвать принципы языка Си?

За 3 месяца ты вряд ли так проникнишься ООП, что процедурный код начнет казаться уродским.
На это потребуется больше 3х лет.

Ну вопревых не CGL, а CGI. Бери его. Раз сервер не твой, нефиг заниматься оптимизацией нагрузки на него, пусть это будет проблема хостера. Зато версия php намного лучше.

Вот даже видео нашел https://www.youtube.com/watch?v=6LOYKoE-mog

Если бы знала - ответила бы. Раз не ответила - значит не знаешь. Все просто и не нужно усложнять.

В best practices по Symfony 4 не рекомендуют создавать бандлы внутри своего приложения

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

SOAP может передаваться и файлами, и через http, да хоть на бумаге. Вообще протокол не описывает способ передачи сообщений, а только их структуру. Передавать и получать завернутые в xml данные может любое клиен-серверное ПО, а "специализированное ПО" нужно для того, чтобы зоворачивать эти данные в xml и извлекать их из него. В качестве ПО типа SOAP UI встречается редко, и применяется в основном в целях отладки.

WSDL - это прикладной xml документ, описывающий структуру конкретного апи. В нем написано, куда слать запросы, какие существуют функции, какие у них аргументы, какой ответ они возвращают, какие существуют типы данных и так далее. В принципе, можно и без него. Нужен он для упрощения интеграции при помощи кодогенерации.

Сообщения JSON это любые сообщения в формате json. Могут иметь любую форму и структуру. В отличии от SOAP, где правила составления всех форм и структур четко регламентированы, сообщения JSON могут быть любыми, какими захочет разработчик. Это ускоряет и удешевляет разработку (любая обезьяна, едва научившись кодить, сварганит тебе говноапи за миску дошика) но усложняет интеграцию.

RMI по сути делает то же самое, только с меньшим количеством оберток. В случае использования XML или JSON апи нужно заворачивать данные в xml/json, потом в http, отправлять на http-сервер, который потом предаст их обработчику запроса, который в свою очередь распарсит xml/json, извлечет оттуда данные и вызовет наконец-то нужную функцию, получит ответ, и прокрутит эту цепочку назад чтобы отдать ответ. RMI же сериализует данные в бинарный вид и отправляет сообщение на сервер через сокет, там их десереализует, выполняет нужную функцию, сериализует ответ и отправляет обратно.

Да, REST - это стиль, который обычно не применяют к SOAP и RMI, которые традиционно придерживаются RPC - стиля. Насколько это в принципе возможно я не знаю, поскольку никогда не пробовал и даже не задумывался об этом.

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

Итого:
1. Нет. Нужно вариться в этом котле, понимание будет приходить со временем и постепенно.
2. FTP, HTTP, Web-Socket, TCP, UDP, XML-RPC, gRPC.
3. Да, можно, но не стоит этого делать, это не самый эффективный способ передачи подобного контента.

1) Контроллер
2) Валидатор
3) Цепочка сервисов
4) Создаешь сущность, пихая данные в конструктор

Этого должно быть достаточно.

В продакшне лучше использовать фреймворк, а в любом современном фреймворке уже есть инструменты для работы с БД, которые на порядок лучше.

Если под "использовать в продакшене" ты имеешь ввиду работу на дядю - то не стоит.

go run main.go

Это вариант запуска при разработке, готовое приложение компилируется и запускается как бинарник, а там уже никакие GOPATH и GOROOT не нужны.

Компиляция делается командой
go build main.go

Подробнее про GOPATH и GOROOT можешь почитать на хабре
https://habr.com/post/249545/

Я бы рекомендовал делать перенаправление на "без слеша". Все-токи при /news/123/ я воспринимаю 123 как папку, а не как конечную страницу. Хотя это вкусовщина, конечно.

В .htaccess убирается так:

RewriteCond %{HTTP_HOST} (.*)
RewriteCond %{REQUEST_URI} /$ [NC]
RewriteRule ^(.*)(/)$ $1 [L,R=301]

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

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