LNK

могу вручную делать return в каждом методе своего API, но это не выглядит правильным

Почему? Это нормальная практика. Каждый метод - это часть контроллера, а контроллер должен возвращать ответ. Ответ в Laravel должен быть инстансом Response (массив автоматически конвертируется в него).

если структура изменится, мне придется менять весь свой код

Для таких случаев Лара предоставляет возможность создать свой собственный тип ответа, например, ApiResponse. Соответственно, после создания будете вызывать в коде как-то так:
return response()->api($code, $data);
Все форматирование будете делать в классе ApiResponse.

Собственно, чтобы создать, регистрируете в сервис-провайдере новый тип response.

Response::macro('api', function ($code, $data) {
    return new ApiResponse($code, $data);
});

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

Стоит ли писать тесты, используя библиотеки?
Да

Стоит ли использовать библиотеку или все таки PHPUnit лучше?
PHPUnit или Codeception

Я бы не советовал так извращаться. У меня на сайте есть вывод городов, и когда мне нужно вывести название города в определенном падеже я использую библиотеку morphos

Для примера чтобы вывести название в предложном падеже я написал в модели метод

public function getNameRpAttribute()
	{
		// Имя в предложном падеже
		return \morphos\Russian\GeographicalNamesInflection::getCase($this->attributes['name_ru'], 'предложный');
	}

С данной библиотекой вы сможете сделать многие вещи касаемые склонений слов и будет вам счастье и счастье человеку которому нужно будет потом редактировать контент

Есть неплохой ресурс для понимания REST www.restapitutorial.ru

1. Апи ВК не rest
2. Rest это то что описано в диссертации Роя Филдинга и в его докладах, блоге. Остальное от лукавого(и от школьников)
3. REST это четкие архитектурные ограничения нужные для того чтобы обеспечить максимальную scalability, и успешно обеспечили, веб разросся до нереальных масштабов. браузер вполне себе rest клиент
4. Реализовывать свой rest клиент это какой-то особый вид извращения, точно так же как и пытаться через rest организовать работу spa/mobile apps, и практически никто из тех кто называет свое апи rest этого не делает
5. Если вы залезли сюда, вам не нужен rest, вам хватит rpc

owasp top10

ВК добавили параметр «Секретный ключ» в настройки Callback API для групп:

Произвольная строка до 50 символов, может включать латинские буквы и цифры.

Заданный Вами секретный ключ будет передаваться с каждым уведомлением от сервера в отдельном поле secret. Это позволит Вам достоверно определять, что уведомление пришло именно от нашего сервера. Чтобы исключить возможность подделки запросов, пожалуйста, не публикуйте значение секретного ключа в открытом доступе.

Судя по документации примерно так (если без cURL):

$context = stream_context_create(array('http' => array(
    'method'  => 'POST',
    'header'  => "Content-Type: application/x-www-form-urlencoded\r\n".
      "Authorization: Basic ".base64_encode("<app key>:<app secret>")."\r\n",
    'content' => http_build_query(array(
    	'code' => <authorization code>,
    	'grant_type' => 'authorization_code',
    	'redirect_uri' => <redirect URI>,
    )),
  )));
                       
$url = 'https://api.dropbox.com/1/oauth2/token';
$result = file_get_contents($url, false, $context);
$result_json = json_decode($result);

echo $result_json->access_token;

SDK у них хорошо расписано, бери да пользуйся.

php.net/manual/ru/book.imagick.php
Да и GD подойдет для ваших потребностей. И текст, и координаты, и прозрачность - всё есть.

1) GD - встроенный
2) ImageMagick - побогаче возможности

Про GitHub.

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

2) Создал себе на Гитхабе две дополнительные организации внутри своего аккаунта.
- «paulradzkov-forks» — для форков чужих проектов.
- «paulradzkov-heaven» — кладбище для старых проектов, куда перемещаются все неактуальные проекты.
Эти две дополнительные организации позволяют очистить основной аккаунт от мусора. В нем теперь только несколько актуальных проектов, в которых легко ориентироваться.

3) Перемещаю все старые проекты из Дропбокса на Гитхаб в «paulradzkov-heaven». Проектов много, это долго, но освободилось уже несколько гигов (т.к. там кроме кода psd-исходники, архивы с инсталляторами и прочее). Место в облаках заканчивается, а на Гитхабе — резиновое.
Это кладбище уже пригодилось, когда у меня попросили поискать исходники проекта, над которым я работал 3 или 4 года назад, а я через минуту ответил им ссылкой на нужный репозиторий. Не пришлось никуда лезть, распаковывать, искать, запаковывать, отправлять почтой или закачивать в облако.
Повторюсь, что на Гитхабе классный поиск по исходникам: если нужно посмотреть, как что-то сделал в старом проекте, но не помнишь в каком — можно довольно быстро найти искомое без возни с архивами.

Итого.
Код должен лежать на Гитхабе.
В том числе старые проекты.
Используйте организации, чтобы рассортировать проекты, если их много.
Порядок там, где у каждой вещи есть своё место. Придумайте себе правила порядка заранее и соблюдайте их, чтобы не тратить время на ликвидацию беспорядка.