CvetKomm, мы специализируемся на разработке мобильных приложений и с радостью поможем Вам! Связаться с нами можно по имейлу info@mobidev.biz или телефону +1 678 701 3551. Посмотреть портфолио можно здесь: mobidev.biz/portfolio/
Это тоже рабочий вариант, но мой велосипед лучше, тем что в качестве PHP Session handler-а я использую модуль написанный на С (redis.so), что должно быть пошустрее, чем использовать обертку из классов на PHP. А еще в перспективе на масштабируемость, я могу указать несколько серверов Redis-а в качестве хранилища сессий, указав приоритеты использования. Вот в таком виде: session.save_path = "tcp://host1:6379?weight=1, tcp://host2:6379?weight=2&timeout=2.5, tcp://host3:6379?weight=2"
не хотелось затрагивать тему REST API, это достойно отдельного топика. Как Вы и сказали, идеология REST API призывает нас не хранить состояние клиента на сервере, то есть не создавать сессии. В этом я вышел за рамки этой идеологии. Но из каких соображений нас призывают к этому? Из-за проблем связанных с масштабируемостью. А теперь вернёмся к статье. Я хотел показать возможность использования родного PHP механизма сессий для авторизации. Он покрывает не малое количество случаев, где нужно писать обработку самостоятельно, в случае чего либо самописного или же вникать в работу openAuth или wsse. В большинстве случаев этого достаточно для использования авторизации при разработке не REST API. Со временем могут возникнуть проблемы масштабируемости из-за того, что сессия хранится на том же сервере куда приходят запросы от клиента. Но здесь приходит на помощь Redis, который легко выносится на отдельный сервер и все остальные балансируемые веб-сервера, которые раньше хранили сессию у себя начинают обращаться к Redis-у. И этого становится достаточно еще на N-ое время. А если нет, то можно смотреть дальше в сторону Redis Cluster…
session.save_path = "tcp://host1:6379?weight=1, tcp://host2:6379?weight=2&timeout=2.5, tcp://host3:6379?weight=2"