This document gives you the basics on securely managing secrets. Most of this document is not directly related to httr, but it’s common to have some secrets to manage whenever you are using an API.
What is a secret? Some secrets are short alphanumeric sequences:
Passwords are clearly secrets, e.g. the second argument to authenticate(). Passwords are particularly important because people (ill-advisedly) often use the same password in multiple places.
Personal access tokens (e.g. github) should be kept secret: they are basically equivalent to a user name password combination, but are slightly safer because you can have multiple tokens for different purposes and it’s easy to invalidate one token without affecting the others.
Surprisingly, the “client secret” in an oauth_app() is not a secret. It’s not equivalent to a password, and if you are writing an API wrapper package, it should be included in the package. (If you don’t believe me, here are google’s comments on the topic.)
Other secrets are files:
The JSON web token (jwt) used for server-to-server OAuth (e.g. google) is a secret because it’s equivalent to a personal access token.
The .httr-oauth file is a secret because it stores OAuth access tokens.
The goal of this vignette is to give you the tools to manage these secrets in a secure way. We’ll start with best practices for managing secrets locally, then talk about sharing secrets with selected others (including travis), and finish with the challenges that CRAN presents.
Here, I assume that the main threat is accidentally sharing your secrets when you don’t want to. Protecting against a committed attacker is much harder. And if someone has already hacked your computer to the point where they can run code, there’s almost nothing you can do. If you’re concerned about those scenarios, you’ll need to take a more comprehensive approach that’s outside the scope of this document.
Working with secret files locally is straightforward because it’s ok to store them in your project directory as long as you take three precautions:
Ensure the file is only readable by you, not by any other user on the system. You can use the R function Sys.chmod() to do so:
It’s good practice to verify this setting by examining the file metadata with your local filesystem GUI tools or commands.
If you use git: make sure the files are listed in .gitignore so they don’t accidentally get included in a public repository.
If you’re making a package: make sure they are listed in .Rbuildignore so they don’t accidentally get included in a public R package.
httr proactively takes all of these steps for you whenever it creates a .httr-oauth file.
The main remaining risk is that you might share the entire directory (i.e. zipping and emailing, or in a public dropbox directory). If you’re worried about this scenario, store your secret files outside of the project directory. If you do this, make sure to provide a helper function to locate the file and provide an informative message if it’s missing.
my_secrets <- function() {
path <- "~/secrets/secret.json"
if (!file.exists(path)) {
stop("Can't find secret file: '", path, "'")
}
jsonlite::read_json(path)
}Storing short secrets is harder because it’s tempting to record them as a variable in your R script. This is a bad idea, because you end up with a file that contains a mix of secret and public code. Instead, you have three options:
Regardless of how you store them, to use your secrets you will still need to read them into R variables. Be careful not to expose them by printing them or saving them to a file.
For scripts that you only use every now and then, a simple solution is to simply ask for the password each time the script is run. If you use RStudio an easy and secure way to request a password is with the rstudioapi package:
If you don’t use RStudio, use a more general solution like the getPass package.
You should never type your password into the R console: this will typically be stored in the .Rhistory file, and it’s easy to accidentally share without realising it.
Asking each time is a hassle, so you might want to store the secret across sessions. One easy way to do that is with environment variables. Environment variables, or envvars for short, are a cross platform way of passing information to processes.
For passing envvars to R, you can list name-value pairs in a file called .Renviron in your home directory. The easiest way to edit it is to run:
The file looks something like
VAR1 = value1
VAR2 = value2And you can access the values in R using Sys.getenv():
Note that .Renviron is only processed on startup, so you’ll need to restart R to see changes.
These environment variables will be available in every running R process, and can easily be read by any other program on your computer to access that file directly. For more security, use the keyring package.
The keyring package provides a way to store (and retrieve) data in your OS’s secure secret store. Keyring has a simple API:
By default, keyring will use the system keyring. This is unlocked by default when you log in, which means while the password is stored securely pretty much any process can access it.
If you want to be even more secure, you can create custom keyring and keep it locked. That will require you to enter a password every time you want to access your secret.
Note that accessing the key always unlocks the keyring, so if you’re being really careful, make sure to lock it again afterwards.
You might wonder if we’ve actually achieved anything here because we still need to enter a password! However, that one password lets you access every secret, and you can control how often you need to re-enter it by manually locking and unlocking the keyring.
There is no way to securely share information with arbitrary R users, including CRAN. That means that if you’re developing a package, you need to make sure that R CMD check passes cleanly even when authentication is not available. This tends to primarily affect the documentation, vignettes, and tests.
Like any R package, an API client needs clear and complete documentation of all functions. Examples are particularly useful but may need to be wrapped in \donttest{} to avoid challenges of authentication, rate limiting, lack of network access, or occasional API server down time.
Vignettes pose additional challenges when an API requires authentication, because you don’t want to bundle your own credentials with the package! However, you can take advantage of the fact that the vignette is built locally, and only checked by CRAN. In a setup chunk, do:
NOT_CRAN <- identical(tolower(Sys.getenv("NOT_CRAN")), "true")
knitr::opts_chunk$set(purl = NOT_CRAN)And then use eval = NOT_CRAN in any chunk that requires access to a secret.
Use testthat::skip() to automatically skip tests that require authentication. I typically will wrap this into a little helper function that I call at the start of every test requiring auth.
So you want to write an R client for a web API? This document walks through the key issues involved in writing API wrappers in R. If you’re new to working with web APIs, you may want to start by reading “An introduction to APIs” by zapier.
APIs vary widely. Before starting to code, it is important to understand how the API you are working with handles important issues so that you can implement a complete and coherent R client for the API.
The key features of any API are the structure of the requests and the structure of the responses. An HTTP request consists of the following parts:
GET, POST, DELETE, etc.)?foo=bar)An API package needs to be able to generate these components in order to perform the desired API call, which will typically involve some sort of authentication.
For example, to request that the GitHub API provides a list of all issues for the httr repo, we send an HTTP request that looks like:
-> GET /repos/hadley/httr HTTP/1.1
-> Host: api.github.com
-> Accept: application/vnd.github.v3+jsonHere we’re using a GET request to the host api.github.com. The url is /repos/hadley/httr, and we send an accept header that tells GitHub what sort of data we want.
In response to this request, the API will return an HTTP response that includes:
An API client needs to parse these responses, turning API errors into R errors, and return a useful object to the end user. For the previous HTTP request, GitHub returns:
<- HTTP/1.1 200 OK
<- Server: GitHub.com
<- Content-Type: application/json; charset=utf-8
<- X-RateLimit-Limit: 5000
<- X-RateLimit-Remaining: 4998
<- X-RateLimit-Reset: 1459554901
<-
<- {
<- "id": 2756403,
<- "name": "httr",
<- "full_name": "hadley/httr",
<- "owner": {
<- "login": "hadley",
<- "id": 4196,
<- "avatar_url": "https://avatars.githubusercontent.com/u/4196?v=3",
<- ...
<- },
<- "private": false,
<- "html_url": "https://github.com/hadley/httr",
<- "description": "httr: a friendly http package for R",
<- "fork": false,
<- "url": "https://api.github.com/repos/hadley/httr",
<- ...
<- "network_count": 1368,
<- "subscribers_count": 64
<- }Designing a good API client requires identifying how each of these API features is used to compose a request and what type of response is expected for each. It’s best practice to insulate the end user from how the API works so they only need to understand how to use an R function, not the details of how APIs work. It’s your job to suffer so that others don’t have to!
First, find a simple API endpoint that doesn’t require authentication: this lets you get the basics working before tackling the complexities of authentication. For this example, we’ll use the list of httr issues which requires sending a GET request to repos/hadley/httr:
library(httr)
github_api <- function(path) {
url <- modify_url("https://api.github.com", path = path)
GET(url)
}
resp <- github_api("/repos/hadley/httr")
resp
#> Response [https://api.github.com/repositories/2756403]
#> Date: 2019-07-30 13:44
#> Status: 200
#> Content-Type: application/json; charset=utf-8
#> Size: 6.04 kB
#> {
#> "id": 2756403,
#> "node_id": "MDEwOlJlcG9zaXRvcnkyNzU2NDAz",
#> "name": "httr",
#> "full_name": "r-lib/httr",
#> "private": false,
#> "owner": {
#> "login": "r-lib",
#> "id": 22618716,
#> "node_id": "MDEyOk9yZ2FuaXphdGlvbjIyNjE4NzE2",
#> ...Next, you need to take the response returned by the API and turn it into a useful object. Any API will return an HTTP response that consists of headers and a body. While the response can come in multiple forms (see above), two of the most common structured formats are XML and JSON.
Note that while most APIs will return only one or the other, some, like the colour lovers API, allow you to choose which one with a url parameter:
GET("http://www.colourlovers.com/api/color/6B4106?format=xml")
#> Response [http://www.colourlovers.com/api/color/6B4106?format=xml]
#> Date: 2019-07-30 13:44
#> Status: 200
#> Content-Type: text/xml; charset=utf-8
#> Size: 1.8 kB
#> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
#> <colors numResults="1" totalResults="10010720">
#> <color>
#> <id>903893</id>
#> <title><![CDATA[wet dirt]]></title>
#> <userName><![CDATA[jessicabrown]]></userName>
#> <numViews>565</numViews>
#> <numVotes>1</numVotes>
#> <numComments>0</numComments>
#> <numHearts>0</numHearts>
#> ...
GET("http://www.colourlovers.com/api/color/6B4106?format=json")
#> Response [http://www.colourlovers.com/api/color/6B4106?format=json]
#> Date: 2019-07-30 13:44
#> Status: 200
#> Content-Type: application/json; charset=utf-8
#> Size: 1.43 kBOthers use content negotiation to determine what sort of data to send back. If the API you’re wrapping does this, then you’ll need to include one of accept_json() and accept_xml() in your request.
If you have a choice, choose json: it’s usually much easier to work with than xml.
Most APIs will return most or all useful information in the response body, which can be accessed using content(). To determine what type of information is returned, you can use http_type()
I recommend checking that the type is as you expect in your helper function. This will ensure that you get a clear error message if the API changes:
github_api <- function(path) {
url <- modify_url("https://api.github.com", path = path)
resp <- GET(url)
if (http_type(resp) != "application/json") {
stop("API did not return json", call. = FALSE)
}
resp
}NB: some poorly written APIs will say the content is type A, but it will actually be type B. In this case you should complain to the API authors, and until they fix the problem, simply drop the check for content type.
Next we need to parse the output into an R object. httr provides some default parsers with content(..., as = "auto") but I don’t recommend using them inside a package. Instead it’s better to explicitly parse it yourself:
jsonlite package.xml2 package.Rather than simply returning the response as a list, I think it’s a good practice to make a simple S3 object. That way you can return the response and parsed object, and provide a nice print method. This will make debugging later on much much much more pleasant.
github_api <- function(path) {
url <- modify_url("https://api.github.com", path = path)
resp <- GET(url)
if (http_type(resp) != "application/json") {
stop("API did not return json", call. = FALSE)
}
parsed <- jsonlite::fromJSON(content(resp, "text"), simplifyVector = FALSE)
structure(
list(
content = parsed,
path = path,
response = resp
),
class = "github_api"
)
}
print.github_api <- function(x, ...) {
cat("<GitHub ", x$path, ">\n", sep = "")
str(x$content)
invisible(x)
}
github_api("/users/hadley")
#> <GitHub /users/hadley>
#> List of 31
#> $ login : chr "hadley"
#> $ id : int 4196
#> $ node_id : chr "MDQ6VXNlcjQxOTY="
#> $ avatar_url : chr "https://avatars3.githubusercontent.com/u/4196?v=4"
#> $ gravatar_id : chr ""
#> $ url : chr "https://api.github.com/users/hadley"
#> $ html_url : chr "https://github.com/hadley"
#> $ followers_url : chr "https://api.github.com/users/hadley/followers"
#> $ following_url : chr "https://api.github.com/users/hadley/following{/other_user}"
#> $ gists_url : chr "https://api.github.com/users/hadley/gists{/gist_id}"
#> $ starred_url : chr "https://api.github.com/users/hadley/starred{/owner}{/repo}"
#> $ subscriptions_url : chr "https://api.github.com/users/hadley/subscriptions"
#> $ organizations_url : chr "https://api.github.com/users/hadley/orgs"
#> $ repos_url : chr "https://api.github.com/users/hadley/repos"
#> $ events_url : chr "https://api.github.com/users/hadley/events{/privacy}"
#> $ received_events_url: chr "https://api.github.com/users/hadley/received_events"
#> $ type : chr "User"
#> $ site_admin : logi FALSE
#> $ name : chr "Hadley Wickham"
#> $ company : chr "@rstudio "
#> $ blog : chr "http://hadley.nz"
#> $ location : chr "Houston, TX"
#> $ email : NULL
#> $ hireable : NULL
#> $ bio : chr "Chief Scientist at @RStudio"
#> $ public_repos : int 219
#> $ public_gists : int 169
#> $ followers : int 16388
#> $ following : int 6
#> $ created_at : chr "2008-04-01T14:47:36Z"
#> $ updated_at : chr "2019-07-30T12:00:45Z"The API might return invalid data, but this should be rare, so you can just rely on the parser to provide a useful error message.
Next, you need to make sure that your API wrapper throws an error if the request failed. Using a web API introduces additional possible points of failure into R code aside from those occurring in R itself. These include:
You need to make sure these are all converted into regular R errors. You can figure out if there’s a problem with http_error(), which checks the HTTP status code. Status codes in the 400 range usually mean that you’ve done something wrong. Status codes in the 500 range typically mean that something has gone wrong on the server side.
Often the API will provide information about the error in the body of the response: you should use this where available. If the API returns special errors for common problems, you might want to provide more detail in the error. For example, if you run out of requests and are rate limited you might want to tell the user how long to wait until they can make the next request (or even automatically wait that long!).
github_api <- function(path) {
url <- modify_url("https://api.github.com", path = path)
resp <- GET(url)
if (http_type(resp) != "application/json") {
stop("API did not return json", call. = FALSE)
}
parsed <- jsonlite::fromJSON(content(resp, "text"), simplifyVector = FALSE)
if (http_error(resp)) {
stop(
sprintf(
"GitHub API request failed [%s]\n%s\n<%s>",
status_code(resp),
parsed$message,
parsed$documentation_url
),
call. = FALSE
)
}
structure(
list(
content = parsed,
path = path,
response = resp
),
class = "github_api"
)
}
github_api("/user/hadley")
#> Error: GitHub API request failed [404]
#> Not Found
#> <https://developer.github.com/v3/users/#get-a-single-user>Some poorly written APIs will return different types of response based on whether or not the request succeeded or failed. If your API does this you’ll need to make your request function check the
status_code()before parsing the response.
For many APIs, the common approach is to retry API calls that return something in the 500 range. However, when doing this, it’s extremely important to make sure to do this with some form of exponential backoff: if something’s wrong on the server-side, hammering the server with retries may make things worse, and may lead to you exhausting quota (or hitting other sorts of rate limits). A common policy is to retry up to 5 times, starting at 1s, and each time doubling and adding a small amount of jitter (plus or minus up to, say, 5% of the current wait time).
While we’re in this function, there’s one important header that you should set for every API wrapper: the user agent. The user agent is a string used to identify the client. This is most useful for the API owner as it allows them to see who is using the API. It’s also useful for you if you have a contact on the inside as it often makes it easier for them to pull your requests from their logs and see what’s going wrong. If you’re hitting a commercial API, this also makes it easier for internal R advocates to see how many people are using their API via R and hopefully assign more resources.
A good default for an R API package wrapper is to make it the URL to your GitHub repo:
ua <- user_agent("http://github.com/hadley/httr")
ua
#> <request>
#> Options:
#> * useragent: http://github.com/hadley/httr
github_api <- function(path) {
url <- modify_url("https://api.github.com", path = path)
resp <- GET(url, ua)
if (http_type(resp) != "application/json") {
stop("API did not return json", call. = FALSE)
}
parsed <- jsonlite::fromJSON(content(resp, "text"), simplifyVector = FALSE)
if (status_code(resp) != 200) {
stop(
sprintf(
"GitHub API request failed [%s]\n%s\n<%s>",
status_code(resp),
parsed$message,
parsed$documentation_url
),
call. = FALSE
)
}
structure(
list(
content = parsed,
path = path,
response = resp
),
class = "github_api"
)
}Most APIs work by executing an HTTP method on a specified URL with some additional parameters. These parameters can be specified in a number of ways, including in the URL path, in URL query arguments, in HTTP headers, and in the request body itself. These parameters can be controlled using httr functions:
modify_url()query argument to GET(), POST(), etc.add_headers()body argument to GET(), POST(), etc.RESTful APIs also use the HTTP verb to communicate arguments (e.g., GET retrieves a file, POST adds a file, DELETE removes a file, etc.). We can use the helpful httpbin service to show how to send arguments in each of these ways.
# modify_url
POST(modify_url("https://httpbin.org", path = "/post"))
# query arguments
POST("http://httpbin.org/post", query = list(foo = "bar"))
# headers
POST("http://httpbin.org/post", add_headers(foo = "bar"))
# body
## as form
POST("http://httpbin.org/post", body = list(foo = "bar"), encode = "form")
## as json
POST("http://httpbin.org/post", body = list(foo = "bar"), encode = "json")Many APIs will use just one of these forms of argument passing, but others will use multiple of them in combination. Best practice is to insulate the user from how and where the various arguments are used by the API and instead simply expose relevant arguments via R function arguments, some of which might be used in the URL, in the headers, in the body, etc.
If a parameter has a small fixed set of possible values that are allowed by the API, you can use list them in the default arguments and then use match.arg() to ensure that the caller only supplies one of those values. (This also allows the user to supply the short unique prefixes.)
It is good practice to explicitly set default values for arguments that are not required to NULL. If there is a default value, it should be the first one listed in the vector of allowed arguments.
Many APIs can be called without any authentication (just as if you called them in a web browser). However, others require authentication to perform particular requests or to avoid rate limits and other limitations. The most common forms of authentication are OAuth and HTTP basic authentication:
“Basic” authentication: This requires a username and password (or sometimes just a username). This is passed as part of the HTTP request. In httr, you can do: GET("http://httpbin.org", authenticate("username", "password"))
Basic authentication with an API key: An alternative provided by many APIs is an API “key” or “token” which is passed as part of the request. It is better than a username/password combination because it can be regenerated independent of the username and password.
This API key can be specified in a number of different ways: in a URL query argument, in an HTTP header such as the Authorization header, or in an argument inside the request body.
OAuth: OAuth is a protocol for generating a user- or session-specific authentication token to use in subsequent requests. (An early standard, OAuth 1.0, is not terribly common any more. See oauth1.0_token() for details.) The current OAuth 2.0 standard is very common in modern web apps. It involves a round trip between the client and server to establish if the API client has the authority to access the data. See oauth2.0_token(). It’s ok to publish the app ID and app “secret” - these are not actually important for security of user data.
Some APIs describe their authentication processes inaccurately, so care needs to be taken to understand the true authentication mechanism regardless of the label used in the API docs.
It is possible to specify the key(s) or token(s) required for basic or OAuth authentication in a number of different ways. You may also need some way to preserve user credentials between function calls so that end users do not need to specify them each time. A good start is to use an environment variable. Here is an example of how to write a function that checks for the presence of a GitHub personal access token and errors otherwise:
One particularly frustrating aspect of many APIs is dealing with paginated responses. This is common in APIs that offer search functionality and have the potential to return a very large number of responses. Responses might be paginated because there is a large number of response elements or because elements are updated frequently. Often they will be sorted by an explicit or implicit argument specified in the request.
When a response is paginated, the API response will typically respond with a header or value specified in the body that contains one of the following:
These values can then be used to make further requests. This will either involve specifying a specific page of responses or specifying a “next page token” that returns the next page of results. How to deal with pagination is a difficult question and a client could implement any of the following:
The choice of which to use depends on your needs and goals and the rate limits of the API.
Many APIs are rate limited, which means that you can only send a certain number of requests per hour. Often if your request is rate limited, the error message will tell you how long you should wait before performing another request. You might want to expose this to the user, or even include a call to Sys.sleep() that waits long enough.
For example, we could implement a rate_limit() function that tells you how many calls against the github API are available to you.
rate_limit <- function() {
github_api("/rate_limit")
}
rate_limit()
#> <GitHub /rate_limit>
#> List of 2
#> $ resources:List of 4
#> ..$ core :List of 3
#> .. ..$ limit : int 60
#> .. ..$ remaining: int 40
#> .. ..$ reset : int 1564497208
#> ..$ search :List of 3
#> .. ..$ limit : int 10
#> .. ..$ remaining: int 10
#> .. ..$ reset : int 1564494311
#> ..$ graphql :List of 3
#> .. ..$ limit : int 0
#> .. ..$ remaining: int 0
#> .. ..$ reset : int 1564497851
#> ..$ integration_manifest:List of 3
#> .. ..$ limit : int 5000
#> .. ..$ remaining: int 5000
#> .. ..$ reset : int 1564497851
#> $ rate :List of 3
#> ..$ limit : int 60
#> ..$ remaining: int 40
#> ..$ reset : int 1564497208After getting the first version working, you’ll often want to polish the output to be more user friendly. For this example, we can parse the unix timestamps into more useful date types.
The goal of this document is to get you up and running with httr as quickly as possible. httr is designed to map closely to the underlying http protocol. I’ll try and explain the basics in this intro, but I’d also recommend “HTTP: The Protocol Every Web Developer Must Know” or “HTTP made really easy”.
This vignette (and parts of the httr API) derived from the excellent “Requests quickstart guide” by Kenneth Reitz. Requests is a python library similar in spirit to httr.
There are two important parts to http: the request, the data sent to the server, and the response, the data sent back from the server. In the first section, you’ll learn about the basics of constructing a request and accessing the response. In the second and third sections, you’ll dive into more details of each.
To make a request, first load httr, then call GET() with a url:
This gives you a response object. Printing a response object gives you some useful information: the actual url used (after any redirects), the http status, the file (content) type, the size, and if it’s a text file, the first few lines of output.
r
#> Response [http://httpbin.org/get]
#> Date: 2019-07-30 13:44
#> Status: 200
#> Content-Type: application/json
#> Size: 315 B
#> {
#> "args": {},
#> "headers": {
#> "Accept": "application/json, text/xml, application/xml, */*",
#> "Accept-Encoding": "gzip, deflate",
#> "Host": "httpbin.org",
#> "User-Agent": "libcurl/7.54.0 r-curl/3.3 httr/1.4.1"
#> },
#> "origin": "73.243.104.136, 73.243.104.136",
#> "url": "https://httpbin.org/get"
#> ...You can pull out important parts of the response with various helper methods, or dig directly into the object:
status_code(r)
#> [1] 200
headers(r)
#> $`access-control-allow-credentials`
#> [1] "true"
#>
#> $`access-control-allow-origin`
#> [1] "*"
#>
#> $`content-encoding`
#> [1] "gzip"
#>
#> $`content-type`
#> [1] "application/json"
#>
#> $date
#> [1] "Tue, 30 Jul 2019 13:44:11 GMT"
#>
#> $`referrer-policy`
#> [1] "no-referrer-when-downgrade"
#>
#> $server
#> [1] "nginx"
#>
#> $`x-content-type-options`
#> [1] "nosniff"
#>
#> $`x-frame-options`
#> [1] "DENY"
#>
#> $`x-xss-protection`
#> [1] "1; mode=block"
#>
#> $`content-length`
#> [1] "217"
#>
#> $connection
#> [1] "keep-alive"
#>
#> attr(,"class")
#> [1] "insensitive" "list"
str(content(r))
#> List of 4
#> $ args : Named list()
#> $ headers:List of 4
#> ..$ Accept : chr "application/json, text/xml, application/xml, */*"
#> ..$ Accept-Encoding: chr "gzip, deflate"
#> ..$ Host : chr "httpbin.org"
#> ..$ User-Agent : chr "libcurl/7.54.0 r-curl/3.3 httr/1.4.1"
#> $ origin : chr "73.243.104.136, 73.243.104.136"
#> $ url : chr "https://httpbin.org/get"I’ll use httpbin.org throughout this introduction. It accepts many types of http request and returns json that describes the data that it received. This makes it easy to see what httr is doing.
As well as GET(), you can also use the HEAD(), POST(), PATCH(), PUT() and DELETE() verbs. You’re probably most familiar with GET() and POST(): GET() is used by your browser when requesting a page, and POST() is (usually) used when submitting a form to a server. PUT(), PATCH() and DELETE() are used most often by web APIs.
The data sent back from the server consists of three parts: the status line, the headers and the body. The most important part of the status line is the http status code: it tells you whether or not the request was successful. I’ll show you how to access that data, then how to access the body and headers.
The status code is a three digit number that summarises whether or not the request was successful (as defined by the server that you’re talking to). You can access the status code along with a descriptive message using http_status():
r <- GET("http://httpbin.org/get")
# Get an informative description:
http_status(r)
#> $category
#> [1] "Success"
#>
#> $reason
#> [1] "OK"
#>
#> $message
#> [1] "Success: (200) OK"
# Or just access the raw code:
r$status_code
#> [1] 200A successful request always returns a status of 200. Common errors are 404 (file not found) and 403 (permission denied). If you’re talking to web APIs you might also see 500, which is a generic failure code (and thus not very helpful). If you’d like to learn more, the most memorable guides are the http status cats.
You can automatically throw a warning or raise an error if a request did not succeed:
I highly recommend using one of these functions whenever you’re using httr inside a function (i.e. not interactively) to make sure you find out about errors as soon as possible.
There are three ways to access the body of the request, all using content():
content(r, "text") accesses the body as a character vector:
r <- GET("http://httpbin.org/get")
content(r, "text")
#> No encoding supplied: defaulting to UTF-8.
#> [1] "{\n \"args\": {}, \n \"headers\": {\n \"Accept\": \"application/json, text/xml, application/xml, */*\", \n \"Accept-Encoding\": \"gzip, deflate\", \n \"Host\": \"httpbin.org\", \n \"User-Agent\": \"libcurl/7.54.0 r-curl/3.3 httr/1.4.1\"\n }, \n \"origin\": \"73.243.104.136, 73.243.104.136\", \n \"url\": \"https://httpbin.org/get\"\n}\n"httr will automatically decode content from the server using the encoding supplied in the content-type HTTP header. Unfortunately you can’t always trust what the server tells you, so you can override encoding if needed:
If you’re having problems figuring out what the correct encoding should be, try stringi::stri_enc_detect(content(r, "raw")).
For non-text requests, you can access the body of the request as a raw vector:
content(r, "raw")
#> [1] 7b 0a 20 20 22 61 72 67 73 22 3a 20 7b 7d 2c 20 0a 20 20 22 68 65 61
#> [24] 64 65 72 73 22 3a 20 7b 0a 20 20 20 20 22 41 63 63 65 70 74 22 3a 20
#> [47] 22 61 70 70 6c 69 63 61 74 69 6f 6e 2f 6a 73 6f 6e 2c 20 74 65 78 74
#> [70] 2f 78 6d 6c 2c 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 6d 6c 2c 20
#> [93] 2a 2f 2a 22 2c 20 0a 20 20 20 20 22 41 63 63 65 70 74 2d 45 6e 63 6f
#> [116] 64 69 6e 67 22 3a 20 22 67 7a 69 70 2c 20 64 65 66 6c 61 74 65 22 2c
#> [139] 20 0a 20 20 20 20 22 48 6f 73 74 22 3a 20 22 68 74 74 70 62 69 6e 2e
#> [162] 6f 72 67 22 2c 20 0a 20 20 20 20 22 55 73 65 72 2d 41 67 65 6e 74 22
#> [185] 3a 20 22 6c 69 62 63 75 72 6c 2f 37 2e 35 34 2e 30 20 72 2d 63 75 72
#> [208] 6c 2f 33 2e 33 20 68 74 74 72 2f 31 2e 34 2e 31 22 0a 20 20 7d 2c 20
#> [231] 0a 20 20 22 6f 72 69 67 69 6e 22 3a 20 22 37 33 2e 32 34 33 2e 31 30
#> [254] 34 2e 31 33 36 2c 20 37 33 2e 32 34 33 2e 31 30 34 2e 31 33 36 22 2c
#> [277] 20 0a 20 20 22 75 72 6c 22 3a 20 22 68 74 74 70 73 3a 2f 2f 68 74 74
#> [300] 70 62 69 6e 2e 6f 72 67 2f 67 65 74 22 0a 7d 0aThis is exactly the sequence of bytes that the web server sent, so this is the highest fidelity way of saving files to disk:
httr provides a number of default parsers for common file types:
# JSON automatically parsed into named list
str(content(r, "parsed"))
#> List of 4
#> $ args : Named list()
#> $ headers:List of 4
#> ..$ Accept : chr "application/json, text/xml, application/xml, */*"
#> ..$ Accept-Encoding: chr "gzip, deflate"
#> ..$ Host : chr "httpbin.org"
#> ..$ User-Agent : chr "libcurl/7.54.0 r-curl/3.3 httr/1.4.1"
#> $ origin : chr "73.243.104.136, 73.243.104.136"
#> $ url : chr "https://httpbin.org/get"See ?content for a complete list.
These are convenient for interactive usage, but if you’re writing an API wrapper, it’s best to parse the text or raw content yourself and check it is as you expect. See the API wrappers vignette for more details.
Access response headers with headers():
headers(r)
#> $`access-control-allow-credentials`
#> [1] "true"
#>
#> $`access-control-allow-origin`
#> [1] "*"
#>
#> $`content-encoding`
#> [1] "gzip"
#>
#> $`content-type`
#> [1] "application/json"
#>
#> $date
#> [1] "Tue, 30 Jul 2019 13:44:11 GMT"
#>
#> $`referrer-policy`
#> [1] "no-referrer-when-downgrade"
#>
#> $server
#> [1] "nginx"
#>
#> $`x-content-type-options`
#> [1] "nosniff"
#>
#> $`x-frame-options`
#> [1] "DENY"
#>
#> $`x-xss-protection`
#> [1] "1; mode=block"
#>
#> $`content-length`
#> [1] "217"
#>
#> $connection
#> [1] "keep-alive"
#>
#> attr(,"class")
#> [1] "insensitive" "list"This is basically a named list, but because http headers are case insensitive, indexing this object ignores case:
Like the response, the request consists of three pieces: a status line, headers and a body. The status line defines the http method (GET, POST, DELETE, etc) and the url. You can send additional data to the server in the url (with the query string), in the headers (including cookies) and in the body of POST(), PUT() and PATCH() requests.
A common way of sending simple key-value pairs to the server is the query string: e.g. http://httpbin.org/get?key=val. httr allows you to provide these arguments as a named list with the query argument. For example, if you wanted to pass key1=value1 and key2=value2 to http://httpbin.org/get you could do:
r <- GET("http://httpbin.org/get",
query = list(key1 = "value1", key2 = "value2")
)
content(r)$args
#> $key1
#> [1] "value1"
#>
#> $key2
#> [1] "value2"Any NULL elements are automatically dropped from the list, and both keys and values are escaped automatically.
You can add custom headers to a request with add_headers():
r <- GET("http://httpbin.org/get", add_headers(Name = "Hadley"))
str(content(r)$headers)
#> List of 6
#> $ Accept : chr "application/json, text/xml, application/xml, */*"
#> $ Accept-Encoding: chr "gzip, deflate"
#> $ Cookie : chr "a=1; b=1"
#> $ Host : chr "httpbin.org"
#> $ Name : chr "Hadley"
#> $ User-Agent : chr "libcurl/7.54.0 r-curl/3.3 httr/1.4.1"(Note that content(r)$header retrieves the headers that httpbin received. headers(r) gives the headers that it sent back in its response.)