The Content-Type header is just used as info for your application. The browser doesn't care what it is. The browser just returns you the data from the AJAX call. If you want to parse it as JSON, you need to do that on your own.

The header is there so your app can detect what data was returned and how it should handle it. You need to look at the header, and if it's application/json then parse it as JSON.

This is actually how jQuery works. If you don't tell it what to do with the result, it uses the Content-Type to detect what to do with it.

Yes, you may use JSON in HTTP headers, given some limitations.

According to the HTTP spec, your header field-body may only contain visible ASCII characters, tab, and space.

Since many JSON encoders (e.g. json_encode in PHP) will encode invisible or non-ASCII characters (e.g. "é" becomes "\u00e9"), you often don't need to worry about this.

Check the docs for your particular encoder or test it, though, because JSON strings technically allow most any Unicode character. For example, in JavaScript JSON.stringify() does not escape multibyte Unicode, by default. However, you can easily modify it to do so, e.g.

var charsToEncode = /[\u007f-\uffff]/g;
function http_header_safe_json(v) {
  return JSON.stringify(v).replace(charsToEncode,
    function(c) {
      return '\\u'+('000'+c.charCodeAt(0).toString(16)).slice(-4);
    }
  );
}

Source

Alternatively, you can do as @rocketspacer suggested and base64-encode the JSON before inserting it into the header field (e.g. how JWT does it). This makes the JSON unreadable (by humans) in the header, but ensures that it will conform to the spec.

Worth noting, the original ARPA spec (RFC 822) has a special description of this exact use case, and the spirit of this echoes in later specs such as RFC 7230:

Certain field-bodies of headers may be interpreted according to an internal syntax that some systems may wish to parse.

Also, RFC 822 and RFC 7230 explicitly give no length constraints:

HTTP does not place a predefined limit on the length of each header field or on the length of the header section as a whole, as described in Section 2.5.

You guessed right, HTTP Headers are not part of the URL.

And when you type a URL in the browser the request will be issued with standard headers. Anyway REST Apis are not meant to be consumed by typing the endpoint in the address bar of a browser.

The most common scenario is that your server consumes a third party REST Api.

To do so your server-side code forges a proper GET (/PUT/POST/DELETE) request pointing to a given endpoint (URL) setting (when needed, like your case) some headers and finally (maybe) sending some data (as typically occurrs in a POST request for example).

The code to forge the request, send it and finally get the response back depends on your server side language.

If you want to test a REST Api you may use curl tool from the command line.

curl makes a request and outputs the response to stdout (unless otherwise instructed).

In your case the test request would be issued like this:

$curl -H "Accept: application/json" 'http://localhost:8080/otp/routers/default/plan?fromPlace=52.5895,13.2836&toPlace=52.5461,13.3588&date=2017/04/04&time=12:00:00'

The H or --header directive sets a header and its value.

You can use this by Creating classes as below :

public class linkedinpostshare_API 
{
public String comment='';
public Content content{get;set;}
public Visibility visibility{get;set;}
public class Content 
{
    public String title='';
    public String description='';
    public String submitted_url='';
    public String submitted_image_url='';        
}
public class Visibility 
{
    public String code='';
} 

}

assign the class properties and make Rest API POST Call As below.

 linkedinpostshare_API objlinkedinpostshare_API = new linkedinpostshare_API();         
     linkedinpostshare_API.Visibility objVisibility = new linkedinpostshare_API.Visibility();

     objVisibility.code='anyone';
     objlinkedinpostshare_API.comment=post;         
     objlinkedinpostshare_API.visibility=objVisibility;       

     String jsonBody = json.serialize(objlinkedinpostshare_API);        
     HttpRequest req = new HttpRequest();
     req.setEndpoint(LINKEDIN_SHAREPOST+token+'&format=json');
     req.setMethod('POST');
     req.setCompressed(false);
     req.setHeader('HOST','www.linkedin.com');
     req.setHeader('Encoding','iso-8859-1'); 
     req.setHeader('Content-Type', LINKEDIN_REQUEST_CONTENTTYPE);
     req.setHeader('x-li-format', 'json');         
     req.setTimeout(120000);//max timeout
      if(jsonBody != null )
         { 
             req.setBody(jsonBody);
             req.setHeader('Content-length',string.valueOf(jsonBody.length()));
         }
         HttpResponse res = new http().send(req);

       return res.getBody();

I agree with sunetos that you'll have to use the $.ajax function in order to pass request headers. In order to do that, you'll have to write a function for the beforeSend event handler, which is one of the $.ajax() options. Here's a quick sample on how to do that:

<html>
  <head>
    <script src="http://code.jquery.com/jquery-1.4.2.min.js"></script>
    <script type="text/javascript">
      $(document).ready(function() {
        $.ajax({
          url: 'service.svc/Request',
          type: 'GET',
          dataType: 'json',
          success: function() { alert('hello!'); },
          error: function() { alert('boo!'); },
          beforeSend: setHeader
        });
      });

      function setHeader(xhr) {
        xhr.setRequestHeader('securityCode', 'Foo');
        xhr.setRequestHeader('passkey', 'Bar');
      }
    </script>
  </head>
  <body>
    <h1>Some Text</h1>
  </body>
</html>

If you run the code above and watch the traffic in a tool like Fiddler, you'll see two requests headers passed in:

• securityCode with a value of Foo
• passkey with a value of Bar

The setHeader function could also be inline in the $.ajax options, but I wanted to call it out.

Hope this helps!