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

Question

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

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

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

Приветствия,

Эндрю

Answer 1

По моему мнению, JSONP может быть достигнут используя GET-глагол.

Да.

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

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

Да.

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

Извинения заблаговременно, если ответ на старый пост - это плохая форма на SO.

@bobince

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

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

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

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

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

Answer 5

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

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