Игорь Русинов

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

Как основной индикатор ошибки API я использую HTTP статусы. Laravel из коробки поддерживает много случаев:

• Если вы используете встроенную валидацию, то Laravel автоматически возвращает HTTP 422 и json массив с ошибками.
  
• Если для получения модели вы используете метод Model::findOrFail(), то Laravel автоматически выбрасывает ModelNotFoundException и автоматически генерирует для него HTTP 404 ответ.
  
• Laravel автоматически возвращает корректный HTTP 4xx ответ, если пользователь не авторизован.
  
• В остальных случаях можно возвращать ошибки вручную, с использованием хелперов, например: abort(403, 'You don\'t have access to do that');
  

Таким образом, вручную ошибки возвращать тоже придется, но в большинстве случаев Laravel сделает это за вас.

Ваши вопросы по порядку:
1. Хорошей практикой считается передача http-заголовка Authorization (все известные мне методы: Basic auth, JWT token, Oauth2 предполагают его использование).
2. Одно из преимуществ, которые я вижу, это возможность быстро проверить какие либо результаты прямо в браузере, т.к. при использовании авторизации через http-заголовок, нужно использовать какой-либо инструмент для тестирования API. Но я бы добавил это только как альтернативный вариант авторизации, например только на тестовом сервере/в локальной среде, и не использовал в продакшене.
3. Никаких граблей со вторым вариантом не встречал, т.к. это стандартный заголовок. Предполагаю, что можно наткнуться на грабли с третьим вариантом, например нестандартные заголовки будут резаться какими-нибудь проксями, кешами.

Использование репозиториев является альтернативой ORM, то есть в этом случае модель Category не должна иметь методов получения или сохранения себя в БД.
Ваш пример будет выглядеть следующим образом:

class CategoryRepository
{
    /*
     * @return Category[]
    */
    public function getAllCategories()
    {
        // Извлекаем категории из БД и создаем массив моделей Category
        return $categories;
    }
}

Соответственно для сохранения категории ваш сервис должен иметь метод CategoryService::save(), в котором будут выполняться необходимые проверки и подготовка данных, а затем вызываться метод репозитория CategoryRepository::save(Category $category).

Если вы не передаете какие-нибудь секретные документы, то вам достаточно будет использовать надежную авторизацию (oauth2, jwt и т.д.) и настроить https соединение на сервере, таким образом ваши данные будут передаваться по сети в зашифрованном виде.

$quotes = ['1a', '1b', '1c'];
echo $quotes[mt_rand(0, count($quotes) - 1)];
...
$quotes = ['2a', '2b', '2c'];
echo $quotes[mt_rand(0, count($quotes) - 1)];
...
и т.д., тоесть нужно заново инициировать массив

Предполагаю, что 5-6 Мб на процесс не так и много, эту память могут просто занимать загруженные библиотеки и модули вашего приложения. Для проверки этой гипотезы создайте скрипт с загрузкой тех же библиотек, что используется в ваших фоновых скриптах, но не извлекающий ничего из базы данных, и замерьте использование памяти. Но, если скрипты начинают использовать больше памяти со временем, то возможно вы не очищаете какие то переменные, например есть массив, в который складываются какие-то данные на каждой итерации, но не очищаются в конце. В таком случае, я думаю, что проблему нужно искать в вашем коде.

Ну если "покопался на хабре/тостере/github/youtube", значит искать информацию умеешь. Стоить начать с самых простых для освоения технологий. Для фронтенда хватит Javascript + jQuery, для карт Google maps или Yandex карты. На бэкенде проще всего начать что-то делать на php. Чат и форум - вполне можно взять полностью готовые решения. Я думаю при большом желании, работающий прототип можно будет в пределах месяца получить, возможно не все запланированные функции, но дальше уже поймете куда двигаться, и все ли функции вам нужны.

Если нужно именно эмулировать поведение пользователя и именно с php, советую присмотреться к Codeсeption с его PhpBrowser (https://www.toptal.com/php/php-testing-with-codeception - по ссылке есть пример с заполнением и отправкой формы).

// Сохранение индекса
var el = $(".elem.current");
var exCurrent = $(".elem").index(el);

// Восстановление по индексу
$('.elem:eq(' + exCurrent + ')').addClass('current');

Что вы подразумеваете под неблокирующим ожиданием? Если подключились - проверили сообщения - отключились - то это предполагает, что такую операцию нужно производить с определенной периодичностью, тогда смысл RabbitMQ в данном сценарии теряется, т.к. можно через определенный интервал времени проверять новые сообщения сразу в СУБД например.
Что касается сообщений и RabbitMQ, то можно создавать 2 очереди, (одну для передачи сообщений, другую для получения). Соответственно для получения сообщений подключаемся к очереди, слушаем из нее сообщения и при получении выдаем пользователю. Для отправки сообщений шлем отдельный запрос во вторую очередь, тут блокировки не будет.

Код инициализации нужно поменять как-то так:

function initialize_map(coords) {
     var latlng = new google.maps.LatLng(49.25100320801442,28.541126489672024);
     var myOptions = {
     zoom: 18,
     center: latlng,
     mapTypeId: google.maps.MapTypeId.ROADMAP
     };
    var map = new google.maps.Map(document.getElementById("map_canvas"), myOptions);
    var length = coords.length;
    var POSITION_X = 0,
    var POSITION_Y = 1;
    var polygonCoords = [];
    for(var i = 0; i < length; i++){
        var point = coords[i];
        polygonCoords.push(new google.maps.LatLng(point[POSITION_X], point[POSITION_Y]));
        console.log();    
    }
     var polygon = new google.maps.Polygon({
      path: polygonCoords,
      strokeColor: "#5196DB",
      strokeOpacity: 1,
      strokeWeight: 2,
      fillColor: "#8ab9e7",
      fillOpacity: 0.5
     });
     polygon.setMap(map);   
     return map;
   }

И при получении координат из запроса вызвать эту функцию:

var coords = info.stops[0].coords[0]; // Получение координат
initialize_map(coords);

Исправленный вариант на jsfiddle: https://jsfiddle.net/99o1h638/

Если проект на php, могу посоветовать https://github.com/robmorgan/phinx

Неплохо было бы взглянуть на полный вывод EXPLAIN ANALYZE, но предполагаю, что причина в том, что первый запрос вытаскивает все данные с диска, а при запуске второго запроса postgresql уже закешировал часть данных. Ну и как сказал He11ion, план запроса тоже кешируется на сессию. Соответственно сравнение не корректное получилось. Если первым запустить поиск с английским словам, а потом по русским, я думаю результат эксперимента будет обратным.