Javascript REST API调用之前对meta的选项调用

我试图了解这个系统是如何运作的。系统是基于

REST

的，这是相当标准的，我不知道的是客户端在每次API调用之前都会进行

OPTIONS

调用，xml内容以这种格式返回。它使用的是Jersey Java

选项

对

删除

方法的响应

访问控制请求方法：在标头中传递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.客户在进行实际呼叫之前，是否先调用

选项

，处理和分析响应，并确定API、参数等，这是标准还是行业惯例？早些时候，我只是查看了文档，并相应地用客户机（javascript）编写了REST调用

---

B.此呼叫是由浏览器自动（飞行前）发出的，还是在客户端编程的？

要了解发生了什么，您需要了解。选项请求是飞行前请求（由浏览器发出，响应客户端试图发出跨源ajax请求），这是向服务器发出的初始请求，用于检查是否允许该客户端向服务器发出请求。飞行前请求发送服务器理解的特定标头，服务器将使用不同的标头进行响应。例如，客户端可能会发送

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

对于这两个请求头，浏览器需要两个相应的响应头。请求头基本上是询问“是否允许此来源”和“是否允许此方法”。服务器应该以

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

上面是响应头，表示允许使用源代码，并且允许使用这些方法。如果您没有看到这些头，这意味着您没有在服务器上配置COR。如果浏览器没有看到这些响应头，它将不会发出实际请求。为了配置CORS，通常使用一个简单的过滤器。有些容器，如Tomcat和Jetty，有一个简单的过滤器实现，您可以配置，也可以自行设计

注意，如上链接所述，上述场景通常仅适用于浏览器和

XmlHTTPRequest

请求

---

XML是什么，就是这个。您获得此功能的唯一原因是，Jersey在默认情况下启用了自己的WADL功能。WADL不是强制性的，但Jersey有它，并且它被配置为响应选项请求。如果禁用WADL（这是可能的），而不是获取XML，则只会得到405 Not Allowed响应，这意味着该端点不允许使用OPTIONS方法。就CORS协议而言，WADL不是标准的。这只是泽西的WADL功能的一个副作用WADL和CORS之间没有任何关系。

谢谢，WADL似乎是一种标准吗？如果我正在为我的客户开发符合REST的服务，我应该提供WADL吗？你不必这样做。但拥有它并没有什么坏处。关于我链接到的Jersey CORS过滤器，需要注意的一点是，它不是一个很好的实现。它甚至不是一个正确的实现（有一天我将不得不更新答案：-）。对于CORS协议，飞行前响应应为200状态，不返回身体。过滤器的更好实现是同时使用请求过滤器和响应过滤器。请求筛选器将检查它是否是带有原始标头的选项请求。如果是，则以200状态中止请求。响应过滤器仍然会被调用添加Headers使用此实现，WADL将永远不会被发送。这是应该发生的。为飞行前请求发送XML会浪费带宽。在请求筛选器（

containerRequestFilter

）中，可以执行

requestContext.abortWith（Response.ok（）.build（））

。这将中止请求，但仍将调用响应筛选器，并添加响应头。