Сергей Протько

Действие update для сущности в рамках REST должно выполняться при помощи PUT запроса.

Фотография пользователя вполне может быть еще одним ресурсом.

Выполнять один и тот же запрос на оба действия

Звучит стремно.

Добавить параметр action к запросу?

Не restful. Больше на RPC похоже.

Создать на сервере классы для управления файловыми операциями и формировать запросы вида /user/4/image/?

users/4/photos или что-то в этом духе.

var data = $.param({
                зфкфьі:  ["apple", "potato"] ,
               
            });

что это?

$http.put('http://*****/mongorest/control/get-menu?'+ data)

ммм... почему у вас данные в query string ложатся а не в тело запроса? Как смысл тогда PUT запрос делать?

Насколько я помню у монги нормальное REST api.

Должно быть как-то так:

$http.put('/some/url', {
    someKey:  ["apple", "potato"] ,
}).then(function (response) {
    // не пользуйтесь .success/.error
}, function (reason) {
    // пользуйтесь только промисами.
});

то есть никаких извращений и подоброго. И не пользуйтесь $.params. Вообще. Для query string у angular есть отдельный параметр в конфигурации запросов.

$http.get('/something', {
    params: {
         query: 'param'
    }
}

и у каждого свой подход

Пожалуй это ключевая фраза. У каждого на самом деле свой подход. Кто-то делает авторизацию исключительно через Yii и потом аунтентификация проходит тупо по кукам, кто-то использует токены, кто-то JWT. Подходов масса.

Основное не понимание как на фронте управлять видимостью различных областей.

У пользователя есть права. Это либо роль, либо список действий которые он может совершать. Словом все примерно как и на бэкэнде. Далее вы можете условия в шаблонах ставить или еще как. Для ангуляра есть несколько подходов организации ACL. В том числе готовых тоже много.

В какую сторону тут копать?

Фронтэнд не сильно отличается от бэкэнда. Вспомните как вы делали приложеньки с обычными формачками и т.д. Вот тоже самое, только теперь у вас нет "перезагрузки", то есть приложение живет пока открыта вкладка. Ну и в качестве базы данных у нас HTTP API какое-то. Вот и вся разница.

Архитектура же приложения примерно такая же. Разве что есть нюансы. UI нужно дробить на независимые маленькие компоненты, желательно не имеющие своего состояния и пробрасывать им оное сверху. Ну и все такое.

angular тут не причем. Это вы уже сами должны разруливать. Так же можете посмотреть на библиотеки для работы с rest api (restangular, ngResource, js-data или любая другая популярная либа).

но тогда теряется идея РЕСТ...

Ну как бы да. Ресурсы это ресурсы. Они никакого отношения к базе не имеют. Но если по какой-то причине вам надо связать ресурсы вместе, то это не проблема. Ваша апишка, если у вас есть за ней контроль, должна быть удобной в использовании в первую очередь, загоны по restfull можно и оставить если это не несет практической пользы.

p.s. если вам не понятно - предлагаю ознакомиться с примерами из jsonapi.org

На что обратить внимание?

www.vinaysahni.com/best-practices-for-a-pragmatic-...

jsonapi.org - можно использовать как стандарт для реализации API.

теряем возможность работы с куки и сессиями

Ну не совсем, с куками вы все так же можете работать и через куки хранить сессии, другое дело что это в 99% не нужно. А токены - JWT решает все проблемы.

не очень удобно и не привычно работать с JS MVC

Привыкните, учитывая то что JS MVC это то, чем должно быть MVC.

сео оптимизация

Тут есть варианты:
- гугловский краулер поддерживает JS нынче, на счет остальные не вкурсе.
- генерация снапшетов (phantomjs например) и Ajax crawling
- server-side рендринг, актуально при втором пункте.

везде нужно тягать токен туда сюда

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

и к нему можем написать клиент на любом php фраэмворке в классическом виде

Почитайте про гексагональную архитектуру, например. HTTP API и классический WEB UI это лишь два интерфейса к одной и той же логике, которая инкапсулирована в сервисы. Разница лишь в том, как DTO из сервисного слоя будет юзаться для формирования представления (будь то json или html).

https://www.youtube.com/watch?v=ajhqScWECMo - вот вам посмотреть на досуге.

Silex, Lumen, Slim...

По хорошему если что-то пошло не так, то падает весь запрос, вся транзакция откатывается и приходится отправлять все заново. Более того, частично обработать коллекцию не выйдет, можно конечно перечислить через запятую айдишки но это не сильно удобно. Все остальное уже выходит за рамки концепции REST и тогда вам в помощь приходит JSON RPC, и тут уж вы сами регламентируете как и что, просто дергать будете POST запрос и все.

1-ый вариант.

GET /api/users/ - все чуваки
GET /api/users/?filter[id]=1,2,7,11,99 - фильтр для выборки по всем чувакам
GET /api/users/5 - чувак с ID 5

jsonapi.org