제 생각에 JSONP는 GET 동사를 사용해야 만 얻을 수 있습니다. 이것이 사실이라고 가정하면 이것이 다른 목적을 위해 GET, PUT, POST, DELETE 등 다른 동사를 사용해야하는 진정한 REST의 핵심 준수를 배제합니다.JSONP 진정한 의미의 결과
get 요청을 사용하여 JSONP 서비스를 사용하여 리소스를 업데이트 및 삭제할 수 있다고 말하는 경우 어떤 유형의 장벽이 발생할지 궁금합니다.
JSON 서비스를 제공하고 사용자가 JavaScript XDomain을 사용하기 위해 서버 측 프록시를 필요로한다고 말하는 것이 더 나은 습관입니까? 그것은 다음 <script> 태그를 사용하여 스크립트를 포함하고 무엇을 처리하는 몇 가지 함수에 콜백을 같이
건배,
앤드류
JSONP 만 달성 할 수 있습니다 GET 동사를 사용합니다.
예.
단순한 멱등 원 (idempotent) 정보 제공 GET 요청은 크로스 도메인 JSON의 가장 일반적인 사용 사례입니다.
이 당신이 DELETE, POST를 GET, 다른 동사 즉의 사용을 PUT해야하는 진정한 REST와 핵심 준수를 배제 등
예.
REST를 추상 표준으로 '준수'하는 데 너무 신경 쓰지는 않지만, 길잃은 누출 가능 캐시 가능 GET 요청으로 인해 우발적 인 부작용이 발생할 수있는 경우 진짜 관심사입니다.
API 사용자 별 및/또는 일회용 제출 키를 매개 변수로 사용하여 조치를 진행할 수 있도록하는 것과 같이 이러한 문제가 발생할 가능성을 줄이려면 전략을 사용할 수 있습니다 . JSONP를 통해 API에 대한 쓰기 액세스를 허용하는 경우 XSRF 공격을 막기 위해 이러한 종류의 문제를 고려해야합니다.
JSONP은 매우 제한적이다.
저는 개인적으로 진정한 서비스를 선호합니다. 서버 측 프록시를 작성하는 것은 그다지 어렵지 않으며 시간 초과, 오류 처리, 다른 유형의 요청 등과 같이 더 많은 것을 제어 할 수 있습니다.
JSONP는 보안 경계 해결책 (동일한 도메인에서만 허용되는 ajax 호출)입니다. 명시된 바와 같이 이것은 매우 제한적이며 읽기 전용 (HTML GET/html 스크립트/src 포함)에서만 사용할 수 있습니다. 이를 위해 실제 api HTTP 요청을 만드는 서버 측 프록시를 가질 필요없이 통합 및 매시업이 쉬워집니다.
하지만 jsonp가 쓰기, 쓰기, 쓰기 등의 일을 할 수 있도록 내 Restful api를 깨뜨리지는 않을 것입니다.
또 다른 큰 단점은 보안입니다. JSONP 호출은 브라우저에 의해 트리거되고 사용자 이름/비밀번호 전송은 작동하지 않습니다 (요청 내에서 분명히 볼 수 있음). 쓰기 동작에 대한 많은 api 비활성화 인증은 no-go입니다. 서버에서 생성 된 일회성 토큰을 사용해도 '컬 (curl)'과 같은 도구를 사용하여 악의적으로 오용 할 수 있기 때문에 위험합니다.
이전 게시물에 답장하는 것이 나쁘면 사전에 사과해야합니다.
@bobince
내가 너무 추상적 인 표준 REST와 '준수'로 방해 아니지만, 길잃은, leakable, 캐시 GET 요청이 실수로 부작용이있을 수 있다면 진짜 문제입니다.
API 사용자 별 및/또는 일회용 제출 키를 매개 변수로 사용하여 조치를 진행할 수 있도록하는 것과 같이 이러한 문제가 발생할 가능성을 줄이려면 전략을 사용할 수 있습니다 . JSONP를 통해 API에 대한 쓰기 액세스를 허용하는 경우 XSRF 공격을 막기 위해 이러한 종류의 문제를 고려해야합니다.
사실 PUT, DELETE 및 POST 동사가 없어서 JSONP에서는 RESTful을 사용할 수 없습니다. 그러나 많은 JSONP API는 여전히 쓰기를 허용합니다. 페이스 북의 OAuth JSONP API에서이를 막연하게 기억하고 있습니다.
"callback ="AND "method ="URL에 모두 존재하고 메소드가 GET, POST, DELETE 또는 DELETE 중 하나 인 경우 서버 측으로 가정하여 가짜 RESTful JSONP API를 구현할 수 있습니다. PUT은 진정한 REST 요청 인 것처럼 처리됩니다.
이렇게하면 콜백이 거의 항상 바뀌고 하나의 리소스 패러다임에 대해 하나의 URL 패러다임이 깨지며 거의 일정하게 유지 되더라도 각 메서드에 대해 하나씩 4 개의 URL 표현이 생성됩니다. 그래서 제 질문은 RESTful 패러다임, 특히 "부작용, 누수 가능성, 캐시 가능 GET 요청"에 대한 우려와 잠재적으로 "[우발적 인] 부작용"으로 인한 이러한 파기의 파급 효과는 무엇입니까?
CORS (Cross Origin Resource Sharing)를 처리하기위한 새로운 기술은 HTTP 액세스 제어를 사용하고 있습니다. 거기에 유익한 문서는 the Kendo Blog에 기사에서 Mozilla Developer pages에에서 찾을 수 있습니다, 및 요약에서 W3 Site
에, 서버 측에서, 당신은 Access-Control 헤더의 몇 가지를 반환해야하는 도움말 액세스를 제어 . 간단한 GET/POST 요청의 경우 단순히 Access-Control-Allow-Origin 헤더를 반환 할 수 있습니다. 다른 메소드를 사용하여 더 복잡한 요청을하려면 위의 리소스에서 찾을 수있는 추가 헤더가 필요합니다.
사실 그렇지만 아직 사용되는 브라우저의 거의 40 % (아직 지원하지 않음) 인 것처럼 보입니다 (http://caniuse.com/cors). – Arjan