RESTful-дизайн социальной сети

Я пытаюсь осмыслить RESTful-дизайн, и я хотел бы понять его с точки зрения социальная сеть. Я прочитал REST API Design Rulebook , искал другие книги и прочитал много онлайн-ресурсов. Тем не менее, применяя правила к реальным проблемам, я понимаю, что не все понимаю полностью. Я хочу знать, правильно ли я понимаю REST, указав некоторые проблемы:

Иерархия против плоского дизайна

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

/users/42

. Теперь фотографии, загруженные этим пользователем, заканчиваются вверху в

/users/42/photos

, и если он / она пометит своих друзей на фотографии, эти теги окажутся в

/users/42/photos/1337/tags

. Но это не дает возможности найти все фотографии, на которых отмечен конкретный пользователь. Следует ли мне придумать для этого другую иерархию? Это кажется немного неудобным. Могу ли я полностью игнорировать иерархию и предоставлять фотографии в сочетании с подобными запросами?

/photos?owner=42
/photos?tagged=42

Кеширование, когда контент отличается для разных пользователей

Веб-сервис должен быть разработан для предоставления кэшируемых данных (чтобы клиент мог решить использовать локальная копия, если она считает, что ничего не было изменено), но как это повлияет на настройки конфиденциальности для разных пользователей? Два пользователя, оба вошли в систему, могут иметь права на просмотр различной информации, например, о пользователь 42.Означает ли это, что мне каким-то образом нужно запрашивать разные URI для разных пользователей, получающих доступ к информации профиля одного и того же пользователя, или кеширование не будет проблемой, если пользователи предоставят разные учетные данные?

Предоставление как HTML, так и JSON / XML из того же ресурса

В упомянутой мной книге указано правило, согласно которому API должен быть доступен в субдомене, начинающемся с api , в их примере http://api.soccer.restapi.org . Я планировал использовать один и тот же контроллер как для доступа пользователей, так и для доступа к машине (например, мобильное приложение). Контроллер будет решать, какое представление предоставить ( text / html , application / json или application / xml ) через поле Accept . в заголовке HTTP-запроса. Я полагаю, что по какой-то причине это было бы плохой идеей (поскольку пользователь ожидал увидеть поддомен www , а не api ), но я не понимаю, почему. Могут ли www и api указывать на один и тот же сервер, или мне действительно стоит попытаться переместить представление HTML на другой виртуальный хост? Почему?

Я считаю, что Ruby on Rails («Соглашение вместо конфигурации») будет предоставлять как HTML, так и JSON от одного и того же контроллера, тем самым разделяя мою идею о том, что HTML и JSON - это просто разные представления одних и тех же данных.

Другими словами, в моей книге говорится, что у определенного ресурса должен быть один и только один URI, и что на основе поля Accept должны предоставляться разные представления.Перенаправление пользователя между разными субдоменами нарушит правило предоставления любого представления из одного и того же ресурса, а дублирование информации (то есть указание двух субдоменов на один и тот же виртуальный хост) нарушает правило о не предоставлении нескольких URI для одного и того же ресурса.Отсутствие поддомена api нарушает еще одно правило проектирования. Как я могу решить эту проблему, не нарушая никаких правил?

Ограничение отправляемых данных

Компонент запроса должен использоваться для разбивки на страницы, но могу ли я отказать в удовлетворении запросов на листинг, не имеющих критериев поиска, и ограничить количество элементов, не нарушая REST? Я хочу как уменьшить нагрузку на базу данных, так и избежать того, чтобы кто-то отображал весь каталог пользователей. Я хочу, чтобы

/users

был недопустимым запросом, а

/users?name=leet+hacker

был бы действительным, но только возвращал, например 100 шт.

Мне также интересно, законно ли возвращать подмножество столбцов базы данных и больше / все из них, только если они специально запрошены с помощью запроса.

Контроллеры, предоставляющие избыточные данные

Я считаю, что предоставление контроллера вроде

/users/me

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

/users/42

, или он должен перенаправлять на него?

Расширенные права для некоторые пользователи

Какой способ RESTful предоставляет дополнительные функции, например права администратора? Теперь я предполагаю, что администратор (фотографии, группы пользователей или всего сайта) сможет видеть больше информации о конкретном объекте, чем другие пользователи.Должна ли эта информация храниться с одним и тем же URI и автоматически отправляться администратору, но не кому-либо еще, должна ли она храниться в другом месте, запрашиваться с помощью определенного запроса администратора или предоставляться другим способом?

Локализация и обновления настроек

Хотя большинство строк, видимых пользователю, должно предоставляться представлением, есть некоторые дизайнерские решения, которые могут включать API. Наиболее очевидны имена. Социальные сети иногда позволяют пользователю вводить разные имена, которые должны отображаться в разных языковых контекстах. Имена на некоторых языках, таких как русский и арабский, нелегко расшифровать автоматически. На других языках, например, на китайском, местные и международные названия могут быть совершенно разными, не иметь никакого сходства или связи. Каким будет RESTful способ справиться с этим? У меня есть ощущение, что ответом будет поле Accept-Language , но серьезно ли кто-нибудь задумывается об этом для переключения языков в социальной сети, к которой они принадлежат? Следует ли всю эту информацию возвращать вызывающему абоненту каждый раз, или можно полагаться на настройки? Будет ли это работать с кешем?