Может ли кто-нибудь придумать аргументы в пользу предоставления journalId в пути? Пример: POST api / journals / {user journalId} / postEntry
Короткий ответ: это нарушение единого ограничения интерфейса.
См. Fielding, 2000 .
То, что вы делаете, по сути, создает этот маленький уголок мира, где вместо использования target-uri для идентификации ресурса вы вместо этого используете target-uri + token.
Это означает, что ваша вещь не использует семантику, которую ожидают компоненты общего назначения в мире.
Например, когда я копирую URI из своего пользовательского агента и делюсь им с кем-то в противном случае этот другой человек не получает ожидаемого результата - они в конечном итоге смотрят свое представление, а не мое.
Тот факт, что мы можем вставить URI в сообщение электронной почты и пусть он просто работает для человека, читающего электронное письмо, - это действительно большой кусок в истории принятия.
Более того, ограничение кеша в REST скорее зависит от возможности использовать идентификатор как в первичный ключ кеша. Таким образом, ваш индивидуальный механизм идентификации может испортить кеширование.
НА ПРАКТИКЕ: вы используете HTTP, а HTTP имеет правила кеширования, которые запрещают совместное использование аутентифицированных запросов. Таким образом, упомянутые выше проблемы кеширования являются чисто теоретическими.
Альтернативы, которые вы можете рассмотреть
- Вы можете организовать перенаправление с
/api/journals/postEntry на с на /api/journals/{userJournalId}/postEntry - Вы можете использовать заголовок Content-Location , чтобы указать, что для текущего представления существует более конкретный c идентификатор.
- Вы можете использовать каноническую ссылку отношение , чтобы помочь клиентам перейти к предпочтительному ресурсу из альтернатив.