Я только начинаю пытаться понять принципы проектирования REST и испытываю трудности с первым примером, который я пробую.
Допустим, я хочу разработать REST API для чего-то вроде SSH-сессии. Не обращая внимания на безопасность, вход в систему и т. Д., Я предполагал, что будет что-то вроде URI / сессий, и я инициирую сеанс SSH, отправив в / сессий указание информации о соединении, имени хоста, имени пользователя и тому подобное. Это приведет к тому, что веб-сервер, обслуживающий REST API, будет инициировать сеанс SSH от моего имени, назначит ему какой-то идентификатор и вернет URI / session / [id]. Затем я мог бы взаимодействовать с этим сеансом с подресурсами этого URI. Это не очень хорошая аналогия с тем, что я хочу сделать, но в ней есть важный момент: попытка определить интерфейс для чего-то, что имеет «сеанс», и чье состояние меняется, когда я отправляю вещи в ресурсы внутри него.
Теперь моя проблема в масштабируемости, но я не могу придумать ничего лучшего. Он полагается на веб-сервер, инициирующий соединение SSH с хостом, и это соединение должно поддерживаться веб-сервером (поэтому будет потеряно, если веб-сервер придется перезапускать). Он также связывает мой запрос с одним веб-сервером - у меня просто не могло быть фермы веб-серверов, обрабатывающих запросы API.
Я мог бы перенести создание и обслуживание SSH-соединений на другой сервер, но это только решило проблему масштабируемости. И в любом случае, тогда мне нужно определить API для этого сервера, и почему бы мне не сделать его REST API, и в этом случае я только что получил дубликат первого, до бесконечности.
Теперь я, возможно, просто смотрю на это неправильно, не будучи достаточно ориентированным на ресурсы, но, на мой взгляд, здесь "ресурс" - это соединение SSH. Моя проблема в том, что ресурс не является чем-то, что легко разделяется - это то, что веб-сервер создает и является по существу временным.
Есть ли какие-нибудь гуру разработки RESTful API, готовые помочь мне в лучшем пути?
Обратите внимание, что я на самом деле не думаю, что это действительно специфично для REST - возникнет существенная проблема проектирования. Я представляю, какой подход я когда-либо использовал, чтобы разработать его как веб-сервис, исходя из того, что взаимодействие с веб-сервисом не требует сохранения состояния.
Спасибо.
[РЕДАКТИРОВАТЬ:] Моя другая проблема с этим подходом - «утечка» ресурсов «сеанса», когда клиенты явно не удаляют их. Самым разумным решением, которое я могу придумать для этого, является определение некоторого свойства сеанса (возможно, устанавливаемого при создании, может быть фиксированного), которое определяет время, к которому вам нужно снова связаться с сеансом, прежде чем он будет считаться устаревшим и удаленным. Клиент получит доступ к этому свойству (скажем, / session [id] / keepalive или что-то в этом роде), которое вернет метку времени, разделит ее на два (хорошо взять точку времени на полпути между сейчас и потом) и убедится, что, если ничего больше, не «опрашивает» сервер, снова получив доступ к тому же ресурсу до этого времени. Если это не удастся, то сеанс будет восстановлен.
Это самый «подход RESTful», который я могу придумать, но он оценил бы более опытные умы RESTful.