Поддержка службы RESTful -Должен ли я использовать Pragma, файлы cookie, настраиваемый заголовок или что-то еще для идентификации клиентских сеансов и транзакций?
Проблема
Мы создаем SOA с RESTful-подходом к сервисам. Как только системы будут запущены в производство, у нас будет много клиентов, использующих интерфейс, включая внутренние и сторонние системы.
Мы хотели бы иметь возможность принимать и отображать ответную информацию, предоставленную клиентским приложением, такую как:-
- Идентификатор сеанса -Может быть идентификатором сеанса Java EE или чем-то еще, относящимся к клиенту, это полезно для группы поддержки и отладки проблем клиентов, чтобы отслеживать их во всех наших системах.
- Идентификатор транзакции -Уникальный идентификатор запроса, который мы можем передать обратно клиенту, чтобы помочь клиенту в сопоставлении запроса и ответа, если он вызывает службу асинхронно или если мы реализуем длительный процесс в стиле 202 Accepted.
Возможные решения
Таким образом, придерживаясь ограничений RESTful, мы должны использовать HTTP для реализации этого, и есть несколько вариантов, которые мы могли бы реализовать.
- Заголовок прагмы -реализует прагмы расширения -для идентификатора транзакции -, идентификатора сеанса -и т. д. Это похоже на чистое решение, поскольку оно использует стандартный заголовок HTTP, хотя я был бы обеспокоен тем, что он стал свалкой для все, о чем мы не можем думать должным образом.
- X -Мой -Заголовок -настраиваемые заголовки для каждого требуемого поля. Может быть удален прокси-серверами, а не основным HTTP, поэтому чувствует себя анти -отдых
- В строке запроса или представлениях XML/JSON -Добавьте поля ко всем нашим ресурсам. Поскольку это рабочий параметр, кажется, что его следует предоставлять в виде метаданных, а не в ресурсе.
- Cookies -используют Cookie и Set -Cookie для хранения значений пользовательского ключа -; полезно в случае идентификаторов сеанса, так как большинство реализаций уже используют файлы cookie. Придется каждый раз повторно отправлять -для поддержки корреляции на стороне клиента, что лишает смысла использование куки.
Ответ
Есть ли прецедент для этого? Мы сумасшедшие? Есть ли что-то очевидное, что я упускаю во всех своих исследованиях? Никого -не волнует, как они будут поддерживать свои сервисы после развертывания? Мне просто заткнуться и уйти?
Я надеюсь, что кто-то может помочь.
P.S. извините, если это немного эссе, в совете было сказано «будьте конкретными»...