Иван Воробей

Пространство освобождается в течение 24 часов после удаления файлов
https://support.google.com/drive/answer/6374270?hl=ru

Все 4 пункта вам поможет сделать онлайн-валидация чека покупки. Вкратце это выглядит так:

1. Приложение получает у iOS чек прилоложения (receipt). При получении его желательно обновить.
2. Приложение отправляет receipt на ваш сервер.
3. Ваш сервер делает запрос в AppStore с этим receipt и shared secret.
4. AppStore возвращает вам json, в котором есть информация о всех покупках в этом приложении пользователя с этим Apple id.
5. В полученной информации нас интересуют:
а) original_purchase_date - дата оформления подписки
б) purchase_date - дата последней оплаты
в) is_trial_period - показывает, что пользователь пользует пробный период
г) cancellation_date - если не равно null, покупка была отменена
6. PROFIT!

Подробно процесс по шагам описан здесь: https://developer.apple.com/library/content/releas...

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

Собсна вопрос: нужно комбинировать rest и сокеты, или переходить исключительно на сокеты?

Собсна, как хотите, так и делайте: REST-полиции и Socket-наци не существует. Принципиально REST API от API на сокетах ничем не отличается (разумеется, я не включаю в это определение пуш данных с сервера). Когда вам на клиенте нужны какие-то данные, вы должны их запросить. А будете вы их получать через ajax или через сокеты совершенно неважно. У меня есть проекты, в которых комбинации самые разные: от чистого REST до чистых сокетов и всё, что посередине.
Но в контексте Laravel вы сокет-сервер не напишете, поэтому, если не хотите менять стек технологий, то используйте так, как предполагается фреймворком: REST API для получения данных, постоянный коннект к какому-нибудь pusher'у на клиенте и отправка туда изменений.

Вариант первый
я так понимаю, что осуществляется примерно следующий воркфлоу:

1. пользователь заходит на страницу
   
2. делает запрос к вашему сервису
   
3. сервис делает запрок к апишке
   
4. сервис получает ответ и вместе с ним изображение
   
5. отдает ответ клиенту
   
6. конец
   

если так, то вы можете получить картинку, сохранить ее, закодить ее в base64, удалить картинку и отдать пользователю картинку в виде base64-строки. браузер умеет отобразить изображение, которое ему подсунули в виде base64-строки
отображать примерно так: jsfiddle.net/casiano/xadvz
минус: если картинка будет большой, то эта строка тоже будет большой. она будет передаваться в отрендереной страница - объем страницы вырастет

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

Вариант третий
хранить файлы изображений в отдельной папке и периодически ее вычищать. дополнительно можно фильтровать файлы, которые удаляете и удалять только те, которые были созданы (mtime) или к ним был доступ (atime) не позже, чем какой-то промежуток времени

Вы наверное это ищите - https://ru.wikipedia.org/wiki/Data:_URL

<img
src="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw
AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz
ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp
a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl
ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis
F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH
hhx4dbgYKAAA7"
alt="Larry" />

Почему не объединить работу в Middleware?

Service Provider и Middleware отвечают за разные вещи. И один не заменяет второй.
Разделение ответсвенности.

Какой практической цели служит Service Provider?

Service Provider умеет делать только что, что от него необходимо. В нем вся логика работы.
Middleware содержит логику для работы с запросом, оно не знает КАК ИМЕННО авторизовывать пользователя. Оно знает что нужно дернуть AuthServiceProvider::guest(), например, и в зависимости от результата пропустить запрос дальше или прервать его.

Для простых приложений это не критично, можно хоть один GodObject на всё сделать, и оно будет работать.
Нужно мысль в плане расширения функционала.

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

То, что вы хотите можно сделать только с клиентами работающими на стороне сервера.

Я думаю, что вам стоит еще раз переосмыслить свою задачу. Возможно стоит описать ситуацию подробнее, почему вы пытаетесь совместить несовместимое, с одной стороны закрытый API и с другой публичное мобильное приложение.

Это так не работает. Нужно выбирать из двух:
1. Публичный API -> Публичный клиент (выполняется на клиенте).
2. Закрытй API -> Закрытый клиент (выполняется на сервере).

Погуглите SSO
https://github.com/jasny/sso

Slim по сути всего лишь предоставляет вам роутер и нифига больше.
Laravel - практически всё что потребуется в процессе разработки.

По результатам раскопок и сделанных выводов опубликовал статью: habrahabr.ru/post/251193