Need help with dropshot?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

oxidecomputer
299 Stars 23 Forks Apache License 2.0 103 Commits 30 Opened issues

Description

expose REST APIs from a Rust program

Services available

!
?

Need anything else?

Contributors list

:showtitle: :toc: left :icons: font

= Dropshot

image::https://github.com/oxidecomputer/dropshot/workflows/Rust/badge.svg[]

Dropshot is a general-purpose crate for exposing REST APIs from a Rust program. For more, see the https://docs.rs/dropshot/[online Dropshot documentation]. You can build the documentation yourself with:

[source,text]

$ cargo +nightly doc

== Contributing

For maintainers (e.g., publishing new releases and managing dependabot), see link:./MAINTAINERS.adoc[MAINTAINERS.adoc].

=== Building and testing

You can build and run the whole test suite with

cargo test
. The test suite runs cleanly and should remain clean.

=== Code formatting and lint

Dropshot works with stable Rust versions, but for consistency the code is formatted with a specific version of

rustfmt
. To contribute to Dropshot, you will need to have installed the
nightly-2021-03-25
version of the Rust toolchain:

$ rustup install nightly-2021-03-25

You can then format the code using

cargo +nightly-2021-03-25 fmt
or
rustfmt +nightly-2021-03-25
. Make sure to run this before pushing changes. The CI uses this version of
rustfmt
to check that the code is correctly formatted.

https://github.com/rust-lang/rust-clippy[Clippy] is used to check for common code issues. (We disable the style checks.) You can run it with

cargo clippy
. CI will run clippy as well.

== Configuration reference

=== Dropshot servers

Dropshot servers use a TOML configuration file. Supported config properties include:

[cols="1,1,1,3",options="header"] |=== |Name |Example |Required? |Description

|

bind_address
|
"127.0.0.1:12220"
|Yes |Specifies that the server should bind to the given IP address and TCP port. In general, servers can bind to more than one IP address and port, but this is not (yet?) supported.

|===

=== Logging

Dropshot provides a small wrapper to configure a slog-based Logger. You can use this without using the rest of Dropshot. Logging config properties include:

[cols="1,1,1,3",options="header"] |=== |Name |Example |Required? |Description

|

mode
|
"file"
|Yes |Controls where server logging will go. Valid modes are
"stderr-terminal"
and
"file".  If the mode is
"stderr-terminal"
, human-readable output, with colors
and other terminal formatting if possible, will be sent to stderr.  If the mode
is
"file"
, Bunyan-format output will be sent to the filesystem path given by
log.path
.  See also
log.if_exists`, which controls the behavior if the destination path already exists.

|

level
|
"info"
|Yes |Specifies what severity of log messages should be included in the log. Valid values include
"trace"
,
"debug"
,
"info"
,
"warn"
,
"error"
, and
"critical"
, which are increasing order of severity. Log messages at the specified level and more severe levels will be included in the log.

|

path
|
"logs/server.log"
|Only if
log.mode = "file"
|If
log.mode
is
"file"
, this property determines the path to the log file. See also
log.if_exists
.

|

if_exists
|
"append"
|Only if
log.mode = "file"
|If
log.mode
is
"file"
, this property specifies what to do if the destination log file already exists. Valid values include
"append"
(which appends to the existing file),
"truncate"
(which truncates the existing file and then uses it as though it had just been created), and
"fail"
(which causes the server to exit immediately with an error).

|===

== Design notes

=== Why is there no way to add an API handler function that runs on every request?

In designing Dropshot, we've tried to avoid a few problems we found with frameworks we used in the past. Many (most?) web frameworks, whether in Rust or another language, let you specify a chain of handlers for each route. You can usually specify some handlers that run before or after every request, regardless of the route. We found that after years of evolving a complex API server using this approach, it can get quite hard to follow the control flow for a particular request and to understand the implicit dependencies between different handlers within the chain. This made it time-consuming and error-prone to work on these API servers. (For more details, see https://github.com/oxidecomputer/dropshot/issues/58#issuecomment-713175039[the discussion in issue 58].)

With Dropshot, we wanted to try something different: if the primary purpose of these handlers is to share code between handlers, what if we rely instead on existing mechanisms -- i.e., function calls. The big risk is that it's easy for someone to accidentally forget some important function call, like the one that authenticates or authorizes a user. We haven't gotten far enough in a complex implementation to need this yet, but the plan is to create a pattern of utility functions that return typed values. For example, where in Node.js you might add an early authentication handler that fills in

request.auth
, with Dropshot you'd have an authentication function that returns an
AuthzContext
struct. Then anything that needs authentication consumes the
AuthzContext
as a function argument. As an author of a handler, you know if you've got an
AuthzContext
available and, if not, how to get one (call the utility function). This composes, too: you can have an authorization function that returns an
AuthnContext
, and the utility function that returns one can consume the
AuthzContext
. Then anything that requires authorization can consume just the
AuthnContext
, and you know it's been authenticated and authorized (possibly with details in that structure).

It's early, and we may find we need richer facilities in the framework. But we're hopeful this approach will make it faster and smoother to iterate on complex API servers. If you pick up Dropshot and try this out, let us know how it goes!

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.