Привет.
Мы тут пытаемся сделать небольшой веб-сервис, и с прототипа, который работает целиком на GET запросах, очень хочется двинуть в сторону настоящего REST. Дабы не углубляться в тему, что есть настоящий труЪ REST, я опишу то, что мы называем этим странным словосочетанием в виде примера.

Допустим, у нас есть такой набор методов:

POST /users - создает нового пользователя, возвращает id новичка.
GET /users - возвращает всех пользователей в системе
PUT /users/:id - обновление пользователя с id = :id
DELETE /users/:id - удаление пользователя.

И все бы казалось хорошо, до тех пор пока мы не добрались до его величества браузера, аякса и кроссдоменных запросов. Дело в том, что каждый PUT и DELETE из браузера предвосхищается т.н. preflight запросом c глаголом OPTION. Этот самый запрос должен вернуть пачку заголовков, в духе: "да, так и быть вам можно совершить этот PUT запрос."

И собственно вот какие вопросы меня беспокоят:
1) Какого черта? Зачем нужен этот OPTION?
2) Можно ли этого как-то избежать?
3) А как поступают корифеи REST? Идея использовать PUT, GET, POST, DELETE запросы выглядит очень многообещающей.

Разумеется, перед тем как задать вопросы, я героически погуглил, и нашел вот что в MDN. Если коротко, то там сказано, что OPTION запрос посылается при аяксовом запросе если он PUT или DELETE, а также в любом случае, если были модифицированы заголовки. Собственно это и было подтверждено практикой. Теперь вопрос: как с этим жить дальше?

iConst,

А как насчет модификации заголовков? Кажется удобным завернуть аутентификацию через HTTP заголовки. При этом снова выплывает метод OPTION, даже при POST и GET.