Вопрос по api, web-services, rest – RESTful API: какую комбинацию METHOD / HEADER использовать только для проверки

6

Я бы хотел, чтобы у моего API был запрос только для проверки. Например, если у меня есть URL-адрес, такой как:

http://api.somesite.com/users/12345

и пользователь заполняет форму информации о клиенте, которую я в конечном итоге ПАТЧИРУЮ / PUT / POST к этому ресурсу. Когда пользователь заполняет форму, я мог бы захотеть периодически отправлять на сервер частично обновленное представление, чтобы я мог отображать в реальном времени подтверждение его ввода (например, «Это имя пользователя уже занято», «Что» пароль слишком короткий & quot;).

Не существует стандартного МЕТОДА HTTP или HEADER, который, по-видимому, допускает такое поведение на том же ресурсе. Похоже, мои варианты:

Create a new subordinate resource for validation Use a custom header (x-somesite-validation-only) and PUT indicating that I want to validate but not save
Связанный вопрос:stackoverflow.com/questions/8368931/… suing
Отличный вопрос Просто столкнулся с этой проблемой, и я спорю между точно такими же двумя подходами. Опираясь на шапку лично. Вдохновленный git 's--dry-run параметр во многих его командах. Aseem Kishore

Ваш Ответ

2   ответа
0

. Эта функция будет отправлять конкретный запрос, когда ей нужна конкретная информация.

Например, вам действительно не нужно отправлять запрос, чтобы проверить, слишком ли короткий пароль. Но вы можете отправить один запрос, чтобы проверить, существует ли имя пользователя.

Вот как проверка выполняется с Ajax, который, кстати, использует Restful API (HTTP) :)

Это вдвое больше объема разработки (то есть на стороне клиента и сервера).
Я бы сказал, что AJAX обязательно использует HTTP в качестве протокола передачи, но не обязательно должен реализовывать методы RESTful как APIin a meaningful way, Говоря "все HTTP RESTful" упускает суть. Fleep
Кроме того, в любом случае я собираюсь выполнить проверку на стороне сервера, и, чтобы не повторяться, я бы предпочел, чтобы мой код проверки был стандартизирован и находился в одном месте. Проверка в реальном времени, которая влияет на пользовательский интерфейс, например проверка пароля, будет хорошо работать с тонкой некритической проверкой на стороне клиента. Но это не замена того, о чем я спрашиваю выше. Fleep
4

1) Используйте пользовательский заголовок
2) Поместите что-нибудь в строку запроса, указывающее только для проверки
3) Используйте Action URl, например. \ IndividualClient \ 123 \ actions \ Validate \ Invoke {раздел 19 здесьhttp://restfulobjects.files.wordpress.com/2011/11/restful-objects-spec-052.pdf}
4) Иерархический URL, например \ IndividualClient \ 123 \ Validation

Из этогосообщение Я нахожу этот совет

Do use POST whenever you have to do something that feels RPC-like Do use GET for things like calculations, unless your input is large, in which case use POST

With regard to your specific question, POST should be used for #4 and #5. These operations fall >under the "RPC-like" guideline above. For #5, remember that POST does not necessarily have to >use Content-Type: application/x-www-form-urlencoded. This could just as easily be a JSON or CSV >payload.

Вот что я рассматриваю:

Это добавление ресурса:
Пользователь / валидация
СООБЩЕНИЕ
Запрос: UserResource
Ответ: ValidationResult
Коды ответа 200, 400. 404. 500

Это обновление ресурса
Пользователь / 204 / проверки
СООБЩЕНИЕ
Запрос: UserResource,
Ответ: ValidationResult Коды ответа 200, 400. 404. 500

В итоге я реализовал нечто очень похожее на это, но чтобы не переписывать мой программный маршрутизатор, я просто включил его в строку запроса: POST / user / 204? Validate Fleep

Похожие вопросы