Как спроектировать REST API для веб-сервиса, у которого метод RPC перегружен

Question

Существующий веб-сервис XML

• Обрабатывает запросы в стиле XML-RPC, в которых элемент операции идентифицирует метод для отправки. Например:

  810 ...

• Количество параметров варьируется.

• Обработчик XML-RPC интерпретирует маркер 810 как означающий две вещи. Если он получает элемент в качестве дочернего элемента , он создает учетную запись. Если вместо этого он получает элемент , он попытается войти в систему пользователя.

Новый дизайн JSON REST API

• Я хочу сохранить это в одной конечной точке REST, например, / апи / Foobar
• Я могу перевести создание пользователя в PUT / api / foobar / $ {user}
• Удаление пользователя в DELETE / api / foobar / $ {user}
• Мой текущий дизайн - сделать POST / api / foobar / $ {user} с телом {"op": "login"} для входа в систему и аналогичным образом для logout, тело {"op": "logout"} будет отправлено.

Что вы, люди, думаете об этом? Кирпичные биты и букеты приветствуются конструктивными комментариями.

Answer 1

Конечная точка должна быть на URI api/users для всех операций CRUD. DELETE и PUT не поддерживаются в формах, созданных с использованием HTML 4, но если вы используете Javascript для связи, то все будет в порядке, но вы можете также представить операции создания и удаления через POST (возможно, передавая _method=PUT|DELETE в полезной нагрузке POST ).

Для входа в систему конечная точка должна быть api/login, но вам лучше использовать HTTP-аутентификацию здесь.

Запрос о проверке дизайна на предмет переполнения стека - это хорошо, но вам лучше не читать архитектуры RESTful, чтобы избежать неправильных поворотов.

Answer 2

Перегруженный POST для RESTful API - это немного клудж, если вы можете избежать этого. В целях входа в систему я предпочел бы попытаться сохранить безгражданство - это будет означать, что клиент должен проходить HTTP-авторизацию при каждом запросе (это означает, что каждый раз передается правильный заголовок авторизации). При первом запросе вы используете один из обычных методов аутентификации, например, Basic.

Answer 3

Как на счет входа в систему и выхода из системы

POST /api/foobar/${user}/loginrequests

POST /api/foobar/${user}/logoutrequests

Сервер на самом деле не должен создавать ресурс «запрос», если вы не хотите, но позже вы можете передумать и захотеть вести учет входов и выходов из системы.