Последствия JSONP с истинным REST

Question

Насколько я понимаю, JSONP может быть достигнуто только с помощью глагола GET. Если предположить, что это правда, что, как мне кажется, верно, то это исключает соответствие ядра истинному REST, в котором вы должны использовать различные глаголы, т. Е. GET, PUT, POST, DELETE и т. Д. ... для различных и конкретных целей.

У меня вопрос, с каким типом барьеров я, скорее всего, столкнусь, если скажу, что разрешить обновление и удаление ресурсов с помощью службы JSONP с помощью запроса get.

Лучше ли предлагать услугу JSON и указывать, что пользователю потребуется прокси-сервер на стороне для использования с использованием JavaScript XDomain?

Ура,

Andrew

Answer 1

Насколько я понимаю, JSONP может быть достигнут только с помощью глагола GET.

Да.

К счастью, простые идемпотентные информационные GET-запросы являются наиболее распространенным вариантом использования междоменного JSON.

это исключает соответствие ядра истинному REST, в котором вы должны использовать различные глаголы, т.е. GET, PUT, POST, DELETE и т. Д.

Да.

Меня не слишком беспокоит «соблюдение» REST в качестве абстрактного стандарта, но реальная проблема в том, что случайные, просачивающиеся, кэшируемые GET-запросы могут случайно иметь побочные эффекты.

Существуют стратегии, которые вы можете использовать для уменьшения вероятности возникновения такого рода проблем, например, требовать, чтобы для каждого пользователя API и / или использовался одноразовый ключ подтверждения в качестве параметра, позволяющего выполнить действие. Если вы разрешаете доступ на запись к API через JSONP, вам все равно придется подумать об этом, чтобы предотвратить атаки XSRF.

Answer 2

Извиняюсь заранее, если ответ на старый пост - плохая форма для SO.

@ bobince

Меня не слишком беспокоит «соблюдение» REST в качестве абстрактного стандарта, но реальная проблема в том, что случайные, просачивающиеся, кэшируемые запросы GET могут случайно иметь побочные эффекты.

Существуют стратегии, которые вы можете использовать для уменьшения вероятности возникновения такого рода проблем, например, требовать, чтобы для каждого пользователя API и / или использовался одноразовый ключ подтверждения в качестве параметра, позволяющего выполнить действие. Если вы разрешаете доступ на запись к API через JSONP, вам все равно придется подумать об этом, чтобы предотвратить атаки XSRF.

Так что истинный RESTful невозможен в JSONP из-за отсутствия глаголов PUT, DELETE и POST. Однако многие API-интерфейсы JSONP по-прежнему разрешают запись. Я смутно припоминаю, что это возможно в API OAuth JSONP Facebook.

Несмотря на это, может показаться, что искусственный RESTful JSONP API может быть достигнут, если предположить, что на стороне сервера присутствуют оба "callback =" И "method =", а метод представляет собой GET, POST, DELETE или PUT тогда он будет обрабатываться так, как если бы это был настоящий запрос REST.

Это нарушает единый URL для единственной ресурсной парадигмы REST, поскольку обратный вызов будет меняться почти каждый раз, и даже если он останется постоянным, будет 4 представления URL, по одному для каждого метода. Поэтому мой вопрос заключается в том, каковы последствия этого разрыва с парадигмой RESTful, особенно в отношении ваших опасений по поводу «случайных, просачивающихся, кешируемых запросов GET» с потенциально «[случайными] побочными эффектами»?

Answer 3

JSONP - это обходной путь безопасности (вызовы ajax разрешены только в одном домене). Как уже говорилось, он очень ограничен и может использоваться только для чтения (HTTP GET через html script / src включает). Для этого он упрощает интеграцию и гибриды без необходимости иметь прокси на стороне сервера, делающего настоящий HTTP-запрос API.

Но я бы никогда не сломал свой Restful API, просто чтобы jsonp do мог выполнять любые действия записи (такие как удаление, создание, запись).

Другим большим недостатком является безопасность: вызовы JSONP запускаются браузером, и передача имени пользователя / пароля не может работать (это было бы ясно видно в запросе). Для многих apis отключенная аутентификация для действий записи не требуется. Даже если вы работаете с одноразовыми токенами, сгенерированными сервером, это опасно, потому что вы можете использовать его злонамеренно, используя такие инструменты, как 'curl'.

Answer 4

JSONP очень ограничен, так как он включает в себя скрипт, использующий тег <script>, а затем выполняет обратный вызов некоторой функции, которая обрабатывает.

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

Answer 5

Новая технология обработки CORS (Cross Origin Resource Sharing) использует HTTP Access Control. Информационную статью об этом можно найти на страницах разработчика Mozilla , на блоге Kendo и на сайте W3

Таким образом, на стороне сервера вам необходимо вернуть пару Access-Control заголовков, которые помогают контролировать доступ. Для простых запросов GET / POST вы можете просто вернуть заголовок Access-Control-Allow-Origin, для более сложных запросов с другими методами вам потребуются дополнительные заголовки, которые можно найти в указанных выше ресурсах.