Question

169

OPTIONS call for meta before REST API call

rated 0 times [ 173] [ 4] / answers: 1 / hits: 17432 / 8 Years ago, mon, july 11, 2016, 12:00:00

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 a OPTIONS call before each API call and XML content is returned in the format. It's using Jersey Java.

OPTIONS response for the DELETE method

Access-Control-Request-Method: DELETE is passed in the headers

<?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://example.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>

Questions:

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. Is this call made by browser automatically (preflight) or was it programmed in the client?

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

andreguym

Add To Favorites

Follow

Total Points: 125

Total Questions: 112

Total Answers: 103

Location: Wallis and Futuna

Member since Tue, Mar 30, 2021

3 Years ago

answered 8 Years ago daquanmilesw · Accepted Answer

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

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.

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

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.