REST API 호출 전에 옵션 호출

이 시스템이 어떻게 작동하는지 이해하려고합니다. 시스템은 REST을 기반으로 꽤 표준이며 클라이언트가 각 API 호출 전에 OPTIONS 호출을 생성하지 못하게하고 XML 콘텐츠가 형식으로 반환됩니다. Jersey Java를 사용하고 있습니다. DELETE 방법REST API 호출 전에 옵션 호출

Access-Control-Request-Method: DELETE에 대한

OPTIONS 응답은 헤더에 전달됩니다

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<application xmlns="http://wadl.dev.java.net/2009/02"> 
    <doc xmlns:jersey="http://jersey.java.net/" jersey:generatedBy="Jersey: 2.8 2014-04-29 01:25:26"/> 
    <grammars/> 
    <resources base=“http://domain.com”> 
     <resource path=“data/gasdfasdg/entity”> 
      <method id="deleteEntity" name="DELETE"> 
       <request> 
        <param xmlns:xs="http://www.w3.org/2001/XMLSchema" type="xs:string"/> 
       </request> 
       <response> 
        <representation mediaType="application/json"/> 
       </response> 
      </method> 
      <method id="getOneEntitysMetadata" name="GET"> 
       <request> 
        <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="q" style="query" type="xs:string"/> 
        <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="x-dps-compute-content-size" style="header" type="xs:boolean"/> 
        <param xmlns:xs="http://www.w3.org/2001/XMLSchema" type="xs:string"/> 
       </request> 
       <response> 
        <representation mediaType="application/json"/> 
       </response> 
      </method> 
      <method id="createOrUpdateEntity" name="PUT"> 
       <request> 
        <param xmlns:xs="http://www.w3.org/2001/XMLSchema" type="xs:string"/> 
       </request> 
       <response> 
        <representation mediaType="application/json"/> 
       </response> 
      </method> 
     </resource> 
    </resources> 
</application>

질문 :

A.는 클라이언트가 처음 OPTIONS를 호출 할 수있는 표준 또는 업계 관행인가 실제 호출을하기 전에 응답을 처리 및 분석하고 API, 매개 변수 등을 결정합니다. 이전에 나는 단지 클라이언트 (자바 스크립트)에서 내 문서를보고 프로그래밍하여 내 REST 호출을 처리했습니다.

B.이 호출은 브라우저에서 자동으로 수행 (프리 플라이트)됩니까? 아니면 클라이언트에서 프로그래밍 되었습니까?

출처

2016-07-11 user2727195

무슨 일이 일어나고 있는지 이해하려면 CORS (cross origin resource sharing)에 대해 알아야합니다. OPTIONS 요청은 비행 전 요청입니다 (브라우저가 교차 원점 아약스 요청을 시도한 것에 대한 응답으로 브라우저가 요청한 것입니다). 이는 서버가 해당 클라이언트가 액세스 할 수 있는지 확인하기위한 초기 요청입니다 서버에 대한 요청 비행 전 요청은 서버가 이해할 수있는 특정 헤더를 보내고 서버는 다른 헤더로 응답합니다. 예를 들어, 클라이언트가 보낼 수도 있습니다.

Origin: http://foo.example 
Access-Control-Request-Method: DELETE

이 두 요청 헤더에는 브라우저에서 예상하는 두 가지 응답 헤더가 있습니다. 요청 헤더는 기본적으로 "이 원본이 허용 되었습니까?"및 "이 메서드가 허용되는지 여부"를 묻습니다. 서버는 다음과 같이 응답해야합니다.

Access-Control-Allow-Origin: http://foo.example 
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE

위의 응답 헤더는 원본이 허용되며 해당 방법이 허용됨을 나타냅니다. 이 헤더가 표시되지 않으면 해당 서버에 CORS가 구성되어 있지 않다는 의미입니다. 브라우저에 해당 응답 헤더가 표시되지 않으면 실제 요청을하지 않습니다. CORS를 구성하려면 일반적으로 간단한 필터가 사용됩니다. Tomcat 및 Jetty와 같은 일부 컨테이너는 구성 할 수있는 간단한 필터 구현을 가지고 있거나 직접 채찍질 할 수도 있습니다 (for example).

위의 시나리오는 위의 링크에서 언급 한대로 일반적으로 브라우저 및 XmlHTTPRequest 요청에만 해당됩니다.

XML이 무엇입니까? WADL입니다. Jersey가 자체 WADL 기능을 기본적으로 사용하도록 설정했기 때문에이 문제가 발생하는 유일한 이유입니다. WADL은 필수 항목이 아니지만 Jersey에 있으며 OPTIONS 요청에 응답하도록 구성되어 있습니다. 가능한 WADL을 비활성화 한 경우 (가능한 경우) XML을 가져 오는 대신 405 Not Allowed 응답 만 받게됩니다. 즉 OPTIONS 메서드가 해당 끝점에 허용되지 않습니다. WADL은 CORS 프로토콜과 관련해서는 표준이 아닙니다. Jersey의 WADL 기능의 부작용입니다. WADL과 CORS는 서로 관련이 없습니다.

출처

2016-07-11 01:55:36

감사합니다. WADL이 표준처럼 보입니다. 내 고객을 위해 REST 호환 서비스를 개발 중이라면 WADL을 제공해야합니까? – user2727195

~하지 마세요. 그것은 그것을 가지고 있지만 상처를주지 않습니다. –

좋아요, 페이지에''컨소시엄은 현재 컨소시엄에 표준화 계획이 없습니다 '', 나에게있어 REST 메서드와 URI 경로만으로도 의도 한 것을 알 수 있으며 스키마에서 구체화 할 수 있습니다. – user2727195

REST API 호출 전에 옵션 호출

답변

관련 문제