API веб-сервиса для проверки параметров, REST или еще?

Question

Я планирую сделать API (как веб-сервис) для проверки ввода пользователя.

API получает 3 параметра от пользователя в качестве входных данных, проверяет все параметры, и возвращает результат (ex: true или false) пользователю.

А вот грубый эскиз к API (я сомневаюсь, что это RESTful):

URL: http://my.domain.com/validate/v1 (POST) 
Required parameter: param1, param2, param3 
Result: To response body (XML/JSON) or response header (HTTP status) 

Но после того, как прибегая к помощи дизайна API и REST я обнаружил, что-то не так с этим дизайном API.

Согласно Wikipedia, запросы и ответы построены вокруг передачи представлений ресурсов. Но API, который я делаю, не имеет ничего общего с ресурсами. Это не CRUD никаких ресурсов. Весь API-интерфейс - это просто ввод данных, проверка их и возвращение результата. И я застрял в разработке API с этим требованием.

Любые советы/исправления к этому вопросу приветствуются.

Answer 1

Вы правы, что ваша проблема лучше соответствует стилю RPC, но его можно легко сопоставить с REST. Вот как бы я это сделал:

Метод POST часто используется в REST для создания нового ресурса. Представление этого нового ресурса отправляется в URL-адрес, представляющий коллекцию ресурсов того же типа. Если операция выполнена успешно, код статуса HTTP «201 создан» возвращается с представлением в теле отдыха (по существу тем же самым телом сообщения, что и тот, который был отправлен в сообщении). В появившемся заголовке Content-Location отображается URL-адрес, назначенный новому ресурсу. Если операция завершается неудачно, она сигнализируется кодом состояния «400 Bad Request» и более подробным описанием ошибки для человека в теле сообщения.

Как вы можете видеть, валидация уже является частью этого общего шаблона REST. Насколько я понимаю, единственное различие в вашем случае состоит в том, что вы не хотите создавать (помнить) этот ресурс на своем сервере. Так не надо. REST не говорит, что вы должны. Если вам станет проще, представьте, что ресурс действительно был временно создан, но сразу же удален. Верните код состояния «200 OK», если параметры проходят проверку, а также возвращают параметры в теле сообщения. Верните «400 Bad Request» в противном случае.

Если глагол «проверять» беспокоит вас в URL-адресе (он не должен), назовите URL-адрес еще что-то, возможно, что-то подходящее имя для объекта, состоящего из трех параметров.

Надеется, что это помогает

Ференцу Михало http://theamiableapi.com