All Projects → Ogeon → Rustful

Ogeon / Rustful

Licence: other
[OUTDATED] A light HTTP framework for Rust

Programming Languages

rust
11053 projects

Projects that are alternatives of or similar to Rustful

Cowboy
Small, fast, modern HTTP server for Erlang/OTP.
Stars: ✭ 6,533 (+653.52%)
Mutual labels:  rest, web-framework
Dropwizard
A damn simple library for building production-ready RESTful web services.
Stars: ✭ 8,078 (+831.72%)
Mutual labels:  rest, web-framework
Farwest
Framework for building RESTful HATEOAS-driven applications.
Stars: ✭ 18 (-97.92%)
Mutual labels:  rest, web-framework
Go Codon
Workflow based REST framework code generator
Stars: ✭ 133 (-84.66%)
Mutual labels:  rest, web-framework
Leptus
The Erlang REST framework
Stars: ✭ 352 (-59.4%)
Mutual labels:  rest, web-framework
Proteus
Lean, mean, and incredibly fast JVM framework for web and microservice development.
Stars: ✭ 178 (-79.47%)
Mutual labels:  rest, web-framework
Foal
Elegant and all-inclusive Node.Js web framework based on TypeScript. 🚀.
Stars: ✭ 1,176 (+35.64%)
Mutual labels:  rest, web-framework
Gramework
Fast and Reliable Golang Web Framework
Stars: ✭ 354 (-59.17%)
Mutual labels:  rest, web-framework
Goyave
🍐 Elegant Golang REST API Framework
Stars: ✭ 811 (-6.46%)
Mutual labels:  rest, web-framework
Grpc Vs Rest
Comparing gRPC + Protobuf with REST + JSON
Stars: ✭ 17 (-98.04%)
Mutual labels:  rest
Hotseat Api
Rest API of a barber shop application - Built with Express, TypeORM and Postgres
Stars: ✭ 27 (-96.89%)
Mutual labels:  rest
Gen
Converts a database into gorm structs and RESTful api
Stars: ✭ 825 (-4.84%)
Mutual labels:  rest
Wordpress Rest Cache
WordPress Plugin to lazy cache HTTP requests in database and update via cron.
Stars: ✭ 8 (-99.08%)
Mutual labels:  rest
Drab
Remote controlled frontend framework for Phoenix.
Stars: ✭ 833 (-3.92%)
Mutual labels:  web-framework
Swagger Codegen Play Scala
Swagger client generator which is based on the PlayWS library
Stars: ✭ 9 (-98.96%)
Mutual labels:  rest
Api Platform
Create REST and GraphQL APIs, scaffold Jamstack webapps, stream changes in real-time.
Stars: ✭ 7,144 (+723.99%)
Mutual labels:  rest
Scala Pet Store
An implementation of the java pet store using FP techniques in scala
Stars: ✭ 812 (-6.34%)
Mutual labels:  rest
Versioning Spring Boot Starter
Spring boot starter using for versioning rest easily.
Stars: ✭ 11 (-98.73%)
Mutual labels:  rest
Go Zero
go-zero is a web and rpc framework written in Go. It's born to ensure the stability of the busy sites with resilient design. Builtin goctl greatly improves the development productivity.
Stars: ✭ 13,156 (+1417.42%)
Mutual labels:  web-framework
Micro Server
Microserver is a Java 8 native, zero configuration, standards based, battle hardened library to run Java Rest Microservices via a standard Java main class. Supporting pure Microservice or Micro-monolith styles.
Stars: ✭ 929 (+7.15%)
Mutual labels:  rest

Rustful

Join the chat at https://gitter.im/Ogeon/rustful

Build Status Windows Build status

A light HTTP framework for Rust, with REST-like features. The main purpose of Rustful is to create a simple, modular and non-intrusive foundation for HTTP applications. It has a mainly stateless structure, which naturally allows it to run both as one single server and as multiple instances in a cluster.

Some of the features are:

  • Generic response handlers. Just use a function or implement the Handler trait.
  • Some handy macros reduces the risk for typos and makes life easier.
  • Variables in routes, that can capture parts of the requested path.
  • Pluggable request and response filtering.

Online documentation.

Getting Started

Cargo.toml Entries

Add the following lines to your Cargo.toml file:

[dependencies]
rustful = "0.9"

Cargo Features

Some parts of Rustful can be toggled using Cargo features:

  • ssl - Enable SSL, and thereby HTTPS. Enabled by default.
  • multipart - Enable parsing of multipart/form-data requests. Enabled by default.

Using SSL

Rustful support SSL (HTTPS), but does not provide the actual SSL connection. It's however compatible with anything that's made for the same Hyper version, so all you have to do is find the one that suits your needs and plug it into the server:

let server_result = Server {
    handlers: router,
    host: 8080.into(),
    ..Server::default()
}.run_https(my_ssl_server);

Write Your Server

Here is a simple example of what a simple project could look like. Visit http://localhost:8080 or http://localhost:8080/Olivia (if your name is Olivia) to try it.

//Include macros to be able to use `insert_routes!`.
#[macro_use]
extern crate log;
extern crate env_logger;

extern crate rustful;

use std::error::Error;

use rustful::{Server, Context, Response, DefaultRouter};

fn say_hello(context: Context, response: Response) {
    //Get the value of the path variable `:person`, from below.
    let person = match context.variables.get("person") {
        Some(name) => name,
        None => "stranger".into()
    };

    //Use the name from the path variable to say hello.
    response.send(format!("Hello, {}!", person));
}

fn main() {
    env_logger::init().unwrap();

    //Create a DefaultRouter and fill it with handlers.
    let mut router = DefaultRouter::<fn(Context, Response)>::new();
    router.build().many(|mut node| {
        //Handle requests for root...
        node.then().on_get(say_hello);

        //...and one level below.
        //`:person` is a path variable and it will be accessible in the handler.
        node.path(":person").then().on_get(say_hello);
    });

    //Build and run the server.
    let server_result = Server {
        handlers: router,

        //Turn a port number into an IPV4 host address (0.0.0.0:8080 in this case).
        host: 8080.into(),

        //Use default values for everything else.
        ..Server::default()
    }.run();

    match server_result {
        Ok(_server) => {},
        Err(e) => error!("could not start server: {}", e.description())
    }
}

Contributing

Contributions are always welcome, even if it's a small typo fix (or maybe I should say "especially typo fixes"). You can fork the project and open a pull request with your changes, or create an issue if you just want to report or request something. Are you not sure about how to implement your change? Is it still a work in progress? Don't worry. You can still open a pull request where we can discuss it and do it step by step.

New features are as welcome as fixes, so pull requests and proposals with enhancements are very much appreciated, but please explain your feature and give a good motivation to why it should be included. It makes things much easier, both for reviewing the feature and for those who are not as familiar with how things work. You can always open an issue where we can discuss the feature and see if it should be included. Asking is better than assuming!

Testing

Rustful is tested on Linux, using Travis, and on Windows, using AppVeyor and a pull request will not be approved unless it passes these tests. It is therefore a good idea to run tests locally, before pushing your changes, so here is a small list of useful commands:

  • cargo test - Basic unit, documentation and compile tests.
  • cargo build --no-default-features - Check if the most minimal version of Rustful builds.
  • cargo build --no-default-features --features "feature1 feature2" - Check if Rustful with only feature1 and feature2 enabled builds.
  • cargo run --example example_name - check if the example example_name behaves as expected (see the example directory).

Travis and AppVeyor will run the tests with the strict feature enabled. This turns warnings and missing documentation into compile errors, which may be harsh, but it's for the sake of the user. Everything should have a description and it's not nice to see warnings from your dependencies when you are compiling your project, right? It's therefore recommend that you run your own tests with the strict feature enabled before pushing, just to see if you missed something.

Automatic Feature Testing

User facing Cargo features are automatically gathered from Cargo.toml and tested one at the time, using scripts/test_features.sh. The lack of public and private features forces us to use a special annotation to differ between internal and user facing feature. Here is an simple example snippet of how the Cargo.toml is expected to look:

#...

[features]
default = ["feature_a", "feature_b"]
feature_a = ["feature_c"]
feature_b = []

#internal
feature_c = []

[dependencies.optional_lib]
#feature
optional=true

#...

Features that are supposed to be available to the user has to be declared before the #internal comment. This will tell the test script that these are supposed to be tested.

Dependency libraries can also be features, so we have to annotate these as well. Each dependency that is supposed to work as a user facing feature will need a #feature comment somewhere within its declaration. This will only work with features that are declared using the above form, and not the feature_lib = { ... } form.

License

Licensed under either of

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].