In contrast with the descriptive
approach in the main vignette (vignette("porcelain")
), this
vignette contains little recipes for exposing and testing different
endpoint types. They are ordered roughly from simplest to most
complicated, and are written as standalone examples (which makes them
quite repetitive!)
Below, we do not use the package convention of wrapping each endpoint in a function. This is to make the examples a little shorter and to make the endpoints more directly callable. In a package, a wrapper function is needed to make the schema path point to the correct place, and to allow binding of state into the endpoint (see later examples).
The one piece of shared code is that we will use a common schema root
This is the example from the main vignette, adding two numbers given
as query parameters and returning a single number. Note that we need to
use jsonlite::unbox()
to indicate that the single number
should be returned as a number and not a vector of length 1 (compare
jsonlite::toJSON(1)
and
jsonlite::toJSON(jsonlite::unbox(1))
)
add <- function(a, b) {
jsonlite::unbox(a + b)
}
endpoint_add <- porcelain::porcelain_endpoint$new(
"GET", "/", add,
porcelain::porcelain_input_query(a = "numeric", b = "numeric"),
returning = porcelain::porcelain_returning_json("numeric", schema_root))
api <- porcelain::porcelain$new(validate = TRUE)$handle(endpoint_add)
Run the endpoint:
api$request("GET", "/", query = list(a = 1, b = 2))
#> $status
#> [1] 200
#>
#> $headers
#> $headers$`x-request-id`
#> [1] "2e1bbb65-d394-48ed-be33-f9f75ba3b000"
#>
#> $headers$`Content-Type`
#> [1] "application/json"
#>
#> $headers$`X-Porcelain-Validated`
#> [1] "true"
#>
#>
#> $body
#> [1] "{\"status\":\"success\",\"errors\":null,\"data\":3}"
Slightly more interesting return type, this time returning a numeric vector.
random <- function(distribution, n) {
switch(distribution,
normal = rnorm(n),
uniform = runif(n),
exponential = rexp(n))
}
endpoint_random <- porcelain::porcelain_endpoint$new(
"GET", "/random/<distribution>", random,
porcelain::porcelain_input_query(n = "numeric"),
returning = porcelain::porcelain_returning_json("numericVector", schema_root))
api <- porcelain::porcelain$new(validate = TRUE)$handle(endpoint_random)
Run the endpoint:
api$request("GET", "/random/normal", query = list(n = 4))
#> $status
#> [1] 200
#>
#> $headers
#> $headers$`x-request-id`
#> [1] "0e424ff5-fbcd-4e8f-b974-49757970c89c"
#>
#> $headers$`Content-Type`
#> [1] "application/json"
#>
#> $headers$`X-Porcelain-Validated`
#> [1] "true"
#>
#>
#> $body
#> [1] "{\"status\":\"success\",\"errors\":null,\"data\":[-0.7855,0.0799,-0.8001,-0.462]}"
api$request("GET", "/random/uniform", query = list(n = 4))
#> $status
#> [1] 200
#>
#> $headers
#> $headers$`x-request-id`
#> [1] "c84bc342-39ae-447a-9d4a-acdbdf1c782d"
#>
#> $headers$`Content-Type`
#> [1] "application/json"
#>
#> $headers$`X-Porcelain-Validated`
#> [1] "true"
#>
#>
#> $body
#> [1] "{\"status\":\"success\",\"errors\":null,\"data\":[0.258,0.2308,0.7664,0.4952]}"
Note that the output here is always a vector, even in the corner cases of 1 and 0 elements returned:
api$request("GET", "/random/normal", query = list(n = 1))
#> $status
#> [1] 200
#>
#> $headers
#> $headers$`x-request-id`
#> [1] "b42d487f-a6f0-441f-8871-695e6ffa91b5"
#>
#> $headers$`Content-Type`
#> [1] "application/json"
#>
#> $headers$`X-Porcelain-Validated`
#> [1] "true"
#>
#>
#> $body
#> [1] "{\"status\":\"success\",\"errors\":null,\"data\":[0.7321]}"
api$request("GET", "/random/normal", query = list(n = 0))
#> $status
#> [1] 200
#>
#> $headers
#> $headers$`x-request-id`
#> [1] "f87bc3b0-b0d3-4647-9069-499f488228e0"
#>
#> $headers$`Content-Type`
#> [1] "application/json"
#>
#> $headers$`X-Porcelain-Validated`
#> [1] "true"
#>
#>
#> $body
#> [1] "{\"status\":\"success\",\"errors\":null,\"data\":[]}"
Here is one way that a complex statistical procedure (here, just
lm
) might be wrapped as an API endpoint. We’ll run a linear
regression against vectors of data x
and y
and
return a table of coefficients.
x <- runif(10)
data <- data.frame(x = x, y = x * 2 + rnorm(length(x), sd = 0.3))
fit <- lm(y ~ x, data)
summary(fit)
#>
#> Call:
#> lm(formula = y ~ x, data = data)
#>
#> Residuals:
#> Min 1Q Median 3Q Max
#> -0.50395 -0.18250 -0.05258 0.25523 0.42008
#>
#> Coefficients:
#> Estimate Std. Error t value Pr(>|t|)
#> (Intercept) -0.1692 0.2355 -0.718 0.492920
#> x 2.2910 0.4480 5.113 0.000915 ***
#> ---
#> Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
#>
#> Residual standard error: 0.3294 on 8 degrees of freedom
#> Multiple R-squared: 0.7657, Adjusted R-squared: 0.7364
#> F-statistic: 26.15 on 1 and 8 DF, p-value: 0.0009147
We’re interested in getting the table of coefficients, which we can extract like this:
summary(fit)$coefficients
#> Estimate Std. Error t value Pr(>|t|)
#> (Intercept) -0.1692312 0.2355472 -0.7184598 0.492920376
#> x 2.2909945 0.4480421 5.1133463 0.000914661
and transform a little to turn the row names into a column of their own
lm_coef <- as.data.frame(summary(fit)$coefficients)
lm_coef <- cbind(name = rownames(lm_coef), lm_coef)
rownames(lm_coef) <- NULL
(the broom
package provides a nice way of doing this
sort of manipulation of these slightly opaque objects). There are many
ways of serialising this sort of data; we will do it in the default way
supported by jsonlite
, representing the object as an array
of objects, each of which is key/value pairs for each row:
jsonlite::toJSON(lm_coef, pretty = TRUE)
#> [
#> {
#> "name": "(Intercept)",
#> "Estimate": -0.1692,
#> "Std. Error": 0.2355,
#> "t value": -0.7185,
#> "Pr(>|t|)": 0.4929
#> },
#> {
#> "name": "x",
#> "Estimate": 2.291,
#> "Std. Error": 0.448,
#> "t value": 5.1133,
#> "Pr(>|t|)": 0.0009
#> }
#> ]
So we have our target function now:
fit_lm <- function(data) {
data <- jsonlite::fromJSON(data)
fit <- lm(y ~ x, data)
lm_coef <- as.data.frame(summary(fit)$coefficients)
lm_coef <- cbind(name = rownames(lm_coef), lm_coef)
rownames(lm_coef) <- NULL
lm_coef
}
Note that the target function must deserialise the json itself. This
is so that arguments can be passed to jsonlite::fromJSON
easily to control how deserialisation happens. We may support automatic
deserialisation later as an argument to
porcelain::porcelain_input_body_json
.
The endpoint is not that much more involved than before though we have interesting inputs and outputs, with schemas required for both
endpoint_lm <- porcelain::porcelain_endpoint$new(
"POST", "/lm", fit_lm,
porcelain::porcelain_input_body_json("data", "lmInputs", schema_root),
returning = porcelain::porcelain_returning_json("lmCoef", schema_root))
The input schema, lmInputs.json
is
{
"$schema": "http://json-schema.org/draft-04/schema#",
"id": "lmInputs",
"type": "array",
"items": {
"type": "object",
"properties": {
"x": {"type": "number"},
"y": {"type": "number"}
},
"required": ["x", "y"],
"additionalProperties": false
}
}
while the response schema lmCoef.json
is
{
"$schema": "http://json-schema.org/draft-04/schema#",
"id": "lmCoef",
"type": "array",
"items": {
"type": "object",
"properties": {
"name": {"type": "string"},
"Estimate": {"type": "number"},
"Std. Error": {"type": "number"},
"t value": {"type": "number"},
"Pr(>|t|)": {"type": "number"}
},
"required": ["name", "Estimate", "Std. Error", "t value", "Pr(>|t|)"],
"additionalProperties": false
}
}
These are both fairly strict schemas using both required
and additionalProperties
. You might want to be more
permissive, but we find that strictness here pays off later.
To exercise the API endpoint we need to pass in our input JSON (not an R object).
json <- jsonlite::toJSON(data)
json
#> [{"x":0.3865,"y":0.4959},{"x":0.4792,"y":1.3486},{"x":0.6702,"y":1.3054},{"x":0.7054,"y":1.3775},{"x":0.1633,"y":-0.1567},{"x":0.0012,"y":0.1059},{"x":0.632,"y":1.2344},{"x":0.7765,"y":1.8138},{"x":0.491,"y":0.4516},{"x":0.41,"y":1.1336}]
api$request("POST", "/lm", body = json, content_type = "application/json")
#> $status
#> [1] 200
#>
#> $headers
#> $headers$`x-request-id`
#> [1] "317d5c70-c58f-4622-b914-d2929eefd8da"
#>
#> $headers$`Content-Type`
#> [1] "application/json"
#>
#> $headers$`X-Porcelain-Validated`
#> [1] "true"
#>
#>
#> $body
#> [1] "{\"status\":\"success\",\"errors\":null,\"data\":[{\"name\":\"(Intercept)\",\"Estimate\":-0.1692,\"Std. Error\":0.2356,\"t value\":-0.7184,\"Pr(>|t|)\":0.4929},{\"name\":\"x\",\"Estimate\":2.2909,\"Std. Error\":0.4481,\"t value\":5.113,\"Pr(>|t|)\":0.0009}]}"
(This example also shows off a few other features)
Handling binary inputs and outputs is supported, provided that you
can deal with them in R. In this example we’ll use R’s serialisation
format (rds; see ?serialize
and ?saveRDS
) as
an example, but this approach would equally work with excel
spreadsheets, zip files or any other non-text data that you work
with.
In this example we’ll take some serialised R data and create a png plot as output. We’ll start by writing our target function:
binary_plot <- function(data, width = 400, height = 400) {
data <- unserialize(data)
tmp <- tempfile(fileext = ".png")
on.exit(unlink(tmp))
png(tmp, width = width, height = height)
tryCatch(
plot(data),
finally = dev.off())
readBin(tmp, raw(), n = file.size(tmp))
}
Here, we use unserialize
to convert the incoming binary
data into something usable, plot to a temporary file (which we clean up
later, using on.exit
). Using
tryCatch(..., finally = dev.off())
ensures that even if the
plotting fails, the device will be closed. Finally, readBin
reads that temporary file in a raw vector.
So, for example (using str
to limit what is printed to
screen)
bin <- serialize(data, NULL)
str(binary_plot(bin), vec.len = 10)
#> raw [1:7578] 89 50 4e 47 0d 0a 1a 0a 00 00 ...
It’s hard to tell this is a png, but the first few bytes give it away
(the magic
number 89 50 4e 47 0d 0a 1a 0a
is used at the start of
all png files).
endpoint_plot <- porcelain::porcelain_endpoint$new(
"POST", "/plot", binary_plot,
porcelain::porcelain_input_body_binary("data"),
returning = porcelain::porcelain_returning_binary())
api <- porcelain::porcelain$new(validate = TRUE)$handle(endpoint_plot)
Making the request (again using str
to prevent printing
thousands of hex characters)
str(api$request("POST", "/plot", body = bin,
content_type = "application/octet-stream"),
vec.len = 10)
#> List of 3
#> $ status : int 200
#> $ headers:List of 3
#> ..$ x-request-id : chr "dc9bed1e-3643-4ca3-b254-09937a0b73e3"
#> ..$ Content-Type : chr "application/octet-stream"
#> ..$ X-Porcelain-Validated: chr "true"
#> $ body : raw [1:7578] 89 50 4e 47 0d 0a 1a 0a 00 00 ...