Whenever an HTTP response includes the message body, there will be a header, Content-Type, that lets the client know what the specific type of content returned in that message body is.
In this case, the GitHub API has returned us some JSON describing this .gitignore template. You can see this encoded in our Content-Type header, along with a parameter specifying the specific character set included in our response.
If we take a look at our request, you can see the client has specified, using the Accept header, that it can accept any kind of Content-Type in the response.
If we had been explicit about our Content-Type we wanted to accept, we can see that our Accept header of application JSON can still be satisfied by the server, and the same content and Content-Type will be returned.
Many APIS will allow you to request the same resource with a different Content-Type that can also be provided. For the GitHub API, if we ask for vin.github.v3.raw, the API will return the raw .gitignore template in our response.
You can see, instead of JSON encoded, we have a raw .gitignore file. The Content-Type is updated to reflect that, to show that instead of returning us JSON, now this exact same resource is returning us this GitHub raw Content-Type.
This Accept header is how we let the server know what Content-Type we wanted. Using Accept headers in this manner is referred to as content negotiation, because we've negotiated specifically the Content-Type our client would like to get returned.
Sometimes, we might request a certain Content-Type that this particular resource can't provide. Here, we've said we would only like to accept text/HTML for this particular resource, but because the GitHub API doesn't know how to return this resource in that media type, it's returned us a 415 status code saying that it's an unsupported media type. It can't return this resource as HTML.
Much like HTTP responses include a Content-Type to specify the type of their message body, HTTP requests that include a message body also include some Content-Type headers. Let's take a look at creating a GitHub issue.
In this case, we use JSON for the request Content-Type by passing in "-j." Our server has responded to our request. Let's take a look at that. Here, our request now has a message body. Because that message body has been coded as JSON, you can see that the Content-Type of our request is included as application JSON.
Because the GitHub server understands how to accept requests with JSON-encoded content, it went ahead and created our issue for us, much like sending a JSON request to our resource.
We could also send a form-urlencoded request. Here, we can see our request Content-Type is now listed as application form-urlencoded, and the request body is encoded to match.
In this case, though, our server, the GitHub API, does not understand how to accept form-urlencoded requests at our particular resource, and it's let us know that by returning a 400 Bad Request response. This is synonymous to sending an Accept header in a Git request with a Content-Type that the server cannot provide.
In this case, we're sending a Content-Type in our message body request that the server can't accept, and so a Bad Request response is returned.