在REST API调用之前,选项将调用meta [英] Options call for meta before REST API call

查看:113
本文介绍了在REST API调用之前,选项将调用meta的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试了解该系统的工作原理.系统是基于REST的,这是非常标准的,在每个API调用和xml内容以该格式返回之前,我没有得到客户端进行的OPTIONS调用.它使用的是Jersey Java.

I'm trying to understand how this system is working under the hood. The system is REST based which is pretty standard, what I don't get the client makes an OPTIONS call before each API call and xml content is returned in the format. It's using Jersey Java.

OPTIONS响应

Access-Control-Request-Method: DELETE在标题中传递

<?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,参数等是标准还是行业惯例?之前,我只是看文档,并相应地在客户端(javascript)中对REST调用进行编程.

A. Is it a standard or industry practice for client to call OPTIONS first, process and analyze the response and determine the API, parameters etc. before making an actual call? Earlier I've been just looking at docs and programming my REST calls in client (javascript) accordingly.

B.此调用是由浏览器自动进行的(预检)还是在客户端中进行了编程?

B. Is this call made by browser automatically (preflight) or was it programmed in the client?

推荐答案

要了解正在发生的事情,您需要了解

To understand what's going on, you need to understand about CORS (cross origin resource sharing). The OPTIONS request , is the pre-flight request (made by the browser, in response to the client trying to make a cross origin ajax request), which is an initial request to the server to check if that client is allowed to make a request to the server. The pre-flight request sends particular headers that the server understands, and the server will response back with different headers. For instance, the client might send

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

使用这两个请求标头,浏览器期望有两个相应的响应标头.请求标头基本上是在询问是否允许此来源"和是否允许此方法".服务器应使用

With these two request headers, there are two corresponding response headers that the browser expects. The request headers are basically asking "is this origin allowed" and "is this method allowed". The servers should respond with

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

上面是响应头,表示允许原点,并且允许这些方法.如果没有看到这些标头,则意味着您的服务器上未配置CORS.如果浏览器没有看到那些响应头,它将不会发出实际的请求.为了配置CORS,通常使用简单的过滤器.某些容器(例如Tomcat和Jetty)具有可以配置的简单过滤器实现,或者您可以自己动手,例如 .

The above are the response headers, saying that the origin is allowed, and that those methods are allowed. If you are not seeing those headers, that means that you do not have CORS configured on your server. If the browser does not see those response headers, it will not make the actual request. To configure CORS, generally a simple filter is used. Some containers, like Tomcat and Jetty, have a simple filter implementation you can configure, or you can just whip up your own, for example.

请注意,如上面的链接所述,上述情况通常仅适用于浏览器和XmlHTTPRequest请求.

Note the above scenario is usually only for browsers and XmlHTTPRequest requests, as mentioned in the above link.

XML是 WADL .收到此消息的唯一原因是,默认情况下,Jersey启用了自己的WADL功能. WADL不是强制性的,但是Jersey拥有WADL,并且它已配置为响应OPTIONS请求.如果禁用了WADL(可能的话),而不是获取XML,您只会得到405 Not Allowed响应,这意味着该端点不允许使用OPTIONS方法.对于CORS协议,WADL并不是标准的东西.这只是Jersey的WADL功能的副作用. WADL和CORS彼此无关.

What the XML is, is that WADL. The only reason you are getting this, is because Jersey has it's own WADL feature enabled by default. WADL is not something that is mandatory, but Jersey has it, and it's configured to respond to OPTIONS requests. If you disabled the WADL (which is possible), instead of getting the XML, you would just get a 405 Not Allowed response, meaning the OPTIONS method is not allowed for that endpoint. The WADL is nothing that is standard is regards to the CORS protocol. It's just a side effect of Jersey's WADL feature. WADL and CORS have nothing to do with each other.

这篇关于在REST API调用之前,选项将调用meta的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆