Comment créer une API REST simple dans Rust

Rust est un langage de programmation multi-paradigmes axé sur les performances et la sécurité, en particulier la concurrence sécurisée. Rust est syntaxiquement similaire à C++, mais assure la sécurité de la mémoire sans utiliser le ramasse-miettes.

Le langage de programmation Rust vous aide à écrire des logiciels plus rapides et plus fiables. L'ergonomie de haut niveau et le contrôle de bas niveau sont souvent en désaccord dans la conception du langage de programmation ; Rust défie ce conflit. En équilibrant une capacité technique puissante et une excellente expérience de développeur, Rust vous offre la possibilité de contrôler les détails de bas niveau (tels que l'utilisation de la mémoire) sans tous les tracas traditionnellement associés à un tel contrôle.

Apprenez à créer une API REST dans Rust - Un guide étape par étape

Pour cela, nous allons utiliser le framework Rocket pour l'API et le framework Diesel ORM pour les fonctionnalités persistantes. Ce cadre couvrira toutes les choses mentionnées ci-dessous. Donc, ce sera beaucoup plus facile que de le mettre en œuvre à partir de zéro.

• Démarrez un serveur Web et ouvrez un PORT.
• Écoutez les requêtes sur ce PORT.
• Si une demande arrive, regardez le chemin dans l'en-tête HTTP.
• Acheminez la demande vers le handlerselon le chemin.
• Vous aider à extraire les informations de la demande.
• Emballez le généré data(créé par vous) et formez un fichier response.
• Renvoyez le responseretour à l'expéditeur.

Installation de Rust tous les soirs

Parce que Rocket utilise abondamment les extensions de syntaxe de Rust et d'autres fonctionnalités avancées et instables, nous devons installer nightly.

rustup default nightly

Si vous préférez installer nightlyuniquement dans votre répertoire de projet, vous pouvez utiliser les éléments suivants :

rustup override set nightly

Dépendances

[dependencies]
rocket = "0.4.4"
rocket_codegen = "0.4.4"
diesel = { version = "1.4.0", features = ["postgres"] }
dotenv = "0.9.0"
r2d2-diesel = "1.0"
r2d2 = "0.8"
serde = "1.0"
serde_derive = "1.0"
serde_json = "1.0"
custom_derive ="0.1.7"

[dependencies.rocket_contrib]
version = "*"
default-features = false
features = ["json"]

J'expliquerai ces caisses une fois que nous les utiliserons.

Configuration du diesel

Donc, la prochaine chose que je vais faire est de configurer Diesel . Diesel fournit sa propre CLI, nous devons donc l'installer en premier. (En supposant que vous utilisez PostgreSQL .)

cargo install diesel_cli — no-default-features — features postgre

Ensuite, vous devez indiquer à Diesel quelles sont vos informations d'identification DB. Cette commande va générer un .envfichier.

echo DATABASE_URL=postgres://username:password@localhost:port/diesel_demo > .env

Après cela, exécutez cette commande :

diesel setup

Cela créera notre base de données (si elle n'existait pas déjà) et créera un répertoire de migrations vide que nous pourrons utiliser pour gérer notre schéma (nous en parlerons plus tard).

Il peut y avoir plusieurs erreurs lors de l'exécution du code ci-dessus.

= note: LINK : fatal error LNK1181: cannot open input file ‘libpq.lib’

Vous pouvez résoudre ce problème facilement en ajoutant le PG lib folderchemin aux variables d'environnement.

setx PQ_LIB_DIR “[path to pg lib folder]”

Je suis surpris que ces erreurs ne soient pas mentionnées dans la doc Diesel .

Je recommande fortement d'exécuter ces commandes dans CMD ou Powershell. Si vous utilisez le terminal d'IDE, vous n'obtiendrez aucune erreur de ce type et vous finirez par perdre deux heures à essayer de comprendre ce qui se passe.

Pour résoudre ce problème, vous pouvez ajouter le chemin du dossier bin de PG aux variables Path. Problème résolu? Bon!

Créons une table utilisateur et créons une migration pour cela :

diesel migration generate users

Après avoir exécuté cette commande, vous verrez qu'il y a deux fichiers générés dans le dossier de migration.

Ensuite, nous écrirons le SQL pour les migrations :

up.sql

CREATE TABLE users
(
    id         SERIAL PRIMARY KEY,
    username   VARCHAR NOT NULL,
    password   VARCHAR NOT NULL,
    first_name VARCHAR NOT NULL
)

down.sql

DROP TABLE users

Pour appliquer notre migration, vous pouvez utiliser :

diesel migration run

Il est bon de s'assurer que down.sqlc'est correct. Vous pouvez rapidement confirmer que vous down.sqlannulez correctement votre migration en refaisant la migration :

diesel migration redo

Vous pouvez voir qu'il y a une table utilisateur dans votre base de données. Droit!

J'ai oublié de mentionner, si vous l'avez remarqué, un fichier est généré après l'exécution de la configuration Diesel nommée schema.rs. Ça devrait ressembler à ça.

table! {
    users (id) {
        id -> Int4,
        username -> Varchar,
        password -> Varchar,
        first_name -> Varchar,
    }
}

Cool, voici la partie rouille

Puisque nous allons utiliser l'ORM, nous devons évidemment mapper la table utilisateur à quelque chose dans Rust. En Java, nous utilisons Class pour mapper les tables. En Java**,** nous les appelons généralement Beans . Dans Rust, nous utilisons structs. Créons un struct.

use diesel;
use diesel::pg::PgConnection;
use diesel::prelude::*;
use super::schema::users;
use super::schema::users::dsl::users as all_users;
// this is to get users from the database
#[derive(Serialize, Queryable)] 
pub struct User {
    pub id: i32,
    pub username: String,
    pub password: String,
    pub first_name: String,
}

Maintenant, vous pouvez vous demander ce que sont ces annotations, comme cette définition de structure ci-dessus.

Ils sont appelés dérives. Ainsi, cette ligne dérivera des traits sérialisés et interrogeables . #[derive(Serialize)]et #[derive(Deserialize)]sont utilisés pour mapper les données à la réponse et à la demande.

Maintenant, je vais créer deux autres structures. Vous les aurez plus tard.

// decode request data
#[derive(Deserialize)] 
pub struct UserData {
    pub username: String,
}
// this is to insert users to database
#[derive(Serialize, Deserialize, Insertable)]
#[table_name = "users"]
pub struct NewUser {
    pub username: String,
    pub password: String,
    pub first_name: String,
}

La prochaine chose que nous allons faire est de mettre en œuvre User. Il aura donc quelques méthodes pour effectuer des opérations de base de données.

Ici, comme vous pouvez le voir, nous avons transmis la connexion à la méthode et renvoyé un vecteur de Users. Nous obtenons toutes les lignes de la table utilisateur et les Usermappons à la structure.

Bien sûr, nous nous attendons à des erreurs. Le message « erreur » sera imprimé en cas de panique.

impl User {

    pub fn get_all_users(conn: &PgConnection) -> Vec<User> {
        all_users
            .order(users::id.desc())
            .load::<User>(conn)
            .expect("error!")
    }

    pub fn insert_user(user: NewUser, conn: &PgConnection) -> bool {
        diesel::insert_into(users::table)
            .values(&user)
            .execute(conn)
            .is_ok()
    }

    pub fn get_user_by_username(user: UserData, conn: &PgConnection) -> Vec<User> {
        all_users
            .filter(users::username.eq(user.username))
            .load::<User>(conn)
            .expect("error!")
    }
}

Nous avons maintenant créé une table et des structures pour mapper cette table. La prochaine chose que nous allons faire est de créer des méthodes pour l'utiliser. Nous allons donc créer un routesfichier. Nous l'appelons généralement un gestionnaire .

use super::db::Conn as DbConn;
use rocket_contrib::json::Json;
use super::models::{User, NewUser};
use serde_json::Value;
use crate::models::UserData;

#[post("/users", format = "application/json")]
pub fn get_all(conn: DbConn) -> Json<Value> {
    let users = User::get_all_users(&conn);
    Json(json!({
        "status": 200,
        "result": users,
    }))
}

#[post("/newUser", format = "application/json", data = "<new_user>")]
pub fn new_user(conn: DbConn, new_user: Json<NewUser>) -> Json<Value> {
    Json(json!({
        "status": User::insert_user(new_user.into_inner(), &conn),
        "result": User::get_all_users(&conn).first(),
    }))
}

#[post("/getUser", format = "application/json", data = "<user_data>")]
pub fn find_user(conn: DbConn, user_data: Json<UserData>) -> Json<Value> {
    Json(json!({
        "status": 200,
        "result": User::get_user_by_username(user_data.into_inner(), &conn),
    }))
}

Maintenant, tout ce que nous avons à faire est de configurer le pool de connexions. Voici une brève explication sur le pool de connexions de la documentation Rocket .

« Rocket inclut une prise en charge intégrée et indépendante de l'ORM pour les bases de données. En particulier, Rocket fournit une macro procédurale qui vous permet de connecter facilement votre application Rocket aux bases de données via des pools de connexions.

Un pool de connexions de base de données est une structure de données qui maintient des connexions de base de données actives pour une utilisation ultérieure dans l'application.

use diesel::pg::PgConnection;
use r2d2;
use r2d2_diesel::ConnectionManager;
use rocket::http::Status;
use rocket::request::{self, FromRequest};
use rocket::{Outcome, Request, State};
use std::ops::Deref;

pub type Pool = r2d2::Pool<ConnectionManager<PgConnection>>;

pub fn init_pool(db_url: String) -> Pool {
    let manager = ConnectionManager::<PgConnection>::new(db_url);
    r2d2::Pool::new(manager).expect("db pool failure")
}

pub struct Conn(pub r2d2::PooledConnection<ConnectionManager<PgConnection>>);

impl<'a, 'r> FromRequest<'a, 'r> for Conn {
    type Error = ();

    fn from_request(request: &'a Request<'r>) -> request::Outcome<Conn, ()> {
        let pool = request.guard::<State<Pool>>()?;
        match pool.get() {
            Ok(conn) => Outcome::Success(Conn(conn)),
            Err(_) => Outcome::Failure((Status::ServiceUnavailable, ())),
        }
    }
}

impl Deref for Conn {
    type Target = PgConnection;

    #[inline(always)]
    fn deref(&self) -> &Self::Target {
        &self.0
    }
}

Enfin, nous devons démarrer notre serveur dans le mainfichier.

#![feature(plugin, const_fn, decl_macro, proc_macro_hygiene)]
#![allow(proc_macro_derive_resolution_fallback, unused_attributes)]

#[macro_use]
extern crate diesel;
extern crate dotenv;
extern crate r2d2;
extern crate r2d2_diesel;
#[macro_use]
extern crate rocket;
extern crate rocket_contrib;
#[macro_use]
extern crate serde_derive;
#[macro_use]
extern crate serde_json;

use dotenv::dotenv;
use std::env;
use routes::*;
use std::process::Command;

mod db;
mod models;
mod routes;
mod schema;

fn rocket() -> rocket::Rocket {
    dotenv().ok();

    let database_url = env::var("DATABASE_URL").expect("set DATABASE_URL");

    let pool = db::init_pool(database_url);
    rocket::ignite()
        .manage(pool)
        .mount(
            "/api/v1/",
            routes![get_all, new_user, find_user],
        )
}

fn main() {
    let _output = if cfg!(target_os = "windows") {
        Command::new("cmd")
            .args(&["/C", "cd ui && npm start"])
            .spawn()
            .expect("Failed to start UI Application")
    } else {
        Command::new("sh")
            .arg("-c")
            .arg("cd ui && npm start")
            .spawn()
            .expect("Failed to start UI Application")
    };
    rocket().launch();
}

Dans mon projet, j'ai également ajouté le frontal angulaire. J'utiliserai également notre back-end Rust pour le servir.

Pour exécuter l'application → cargo run.

Testons notre serveur avec Insomnia .

J'espère que ça aide. À votre santé!

What is GEEK

Buddha Community

What is REST API? An Overview | Liquid Web

What is REST?

The REST acronym is defined as a “REpresentational State Transfer” and is designed to take advantage of existing HTTP protocols when used for Web APIs. It is very flexible in that it is not tied to resources or methods and has the ability to handle different calls and data formats. Because REST API is not constrained to an XML format like SOAP, it can return multiple other formats depending on what is needed. If a service adheres to this style, it is considered a “RESTful” application. REST allows components to access and manage functions within another application.

REST was initially defined in a dissertation by Roy Fielding’s twenty years ago. He proposed these standards as an alternative to SOAP (The Simple Object Access Protocol is a simple standard for accessing objects and exchanging structured messages within a distributed computing environment). REST (or RESTful) defines the general rules used to regulate the interactions between web apps utilizing the HTTP protocol for CRUD (create, retrieve, update, delete) operations.

What is an API?

An API (or Application Programming Interface) provides a method of interaction between two systems.

What is a RESTful API?

A RESTful API (or application program interface) uses HTTP requests to GET, PUT, POST, and DELETE data following the REST standards. This allows two pieces of software to communicate with each other. In essence, REST API is a set of remote calls using standard methods to return data in a specific format.

The systems that interact in this manner can be very different. Each app may use a unique programming language, operating system, database, etc. So, how do we create a system that can easily communicate and understand other apps?? This is where the Rest API is used as an interaction system.

When using a RESTful API, we should determine in advance what resources we want to expose to the outside world. Typically, the RESTful API service is implemented, keeping the following ideas in mind:

• Format: There should be no restrictions on the data exchange format
• Implementation: REST is based entirely on HTTP
• Service Definition: Because REST is very flexible, API can be modified to ensure the application understands the request/response format.
• The RESTful API focuses on resources and how efficiently you perform operations with it using HTTP.

The features of the REST API design style state:

• Each entity must have a unique identifier.
• Standard methods should be used to read and modify data.
• It should provide support for different types of resources.
• The interactions should be stateless.

For REST to fit this model, we must adhere to the following rules:

• Client-Server Architecture: The interface is separate from the server-side data repository. This affords flexibility and the development of components independently of each other.
• Detachment: The client connections are not stored on the server between requests.
• Cacheability: It must be explicitly stated whether the client can store responses.
• Multi-level: The API should work whether it interacts directly with a server or through an additional layer, like a load balancer.

#tutorials #api #application #application programming interface #crud #http #json #programming #protocols #representational state transfer #rest #rest api #rest api graphql #rest api json #rest api xml #restful #soap #xml #yaml

An API-First Approach For Designing Restful APIs | Hacker Noon

I’ve been working with Restful APIs for some time now and one thing that I love to do is to talk about APIs.

So, today I will show you how to build an API using the API-First approach and Design First with OpenAPI Specification.

First thing first, if you don’t know what’s an API-First approach means, it would be nice you stop reading this and check the blog post that I wrote to the Farfetchs blog where I explain everything that you need to know to start an API using API-First.

Preparing the ground

Before you get your hands dirty, let’s prepare the ground and understand the use case that will be developed.

Tools

If you desire to reproduce the examples that will be shown here, you will need some of those items below.

• NodeJS
• OpenAPI Specification
• Text Editor (I’ll use VSCode)
• Command Line

Use Case

To keep easy to understand, let’s use the Todo List App, it is a very common concept beyond the software development community.

#api #rest-api #openai #api-first-development #api-design #apis #restful-apis #restful-api

Opencart REST API extensions - V3.x | Rest API Integration, Affiliate

Opencart REST API extensions - V3.x | Rest API Integration : OpenCart APIs is fully integrated with the OpenCart REST API. This is interact with your OpenCart site by sending and receiving data as JSON (JavaScript Object Notation) objects. Using the OpenCart REST API you can register the customers and purchasing the products and it provides data access to the content of OpenCart users like which is publicly accessible via the REST API. This APIs also provide the E-commerce Mobile Apps.

Opencart REST API 
OCRESTAPI Module allows the customer purchasing product from the website it just like E-commerce APIs its also available mobile version APIs.

Opencart Rest APIs List 
Customer Registration GET APIs.
Customer Registration POST APIs.
Customer Login GET APIs.
Customer Login POST APIs.
Checkout Confirm GET APIs.
Checkout Confirm POST APIs.

If you want to know Opencart REST API Any information, you can contact us at -
Skype: jks0586,
Email: letscmsdev@gmail.com,
Website: www.letscms.com, www.mlmtrees.com
Call/WhatsApp/WeChat: +91–9717478599.

Download : https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=43174&filter_search=ocrest%20api
View Documentation : https://www.letscms.com/documents/api/opencart-rest-api.html
More Information : https://www.letscms.com/blog/Rest-API-Opencart
VEDIO : https://vimeo.com/682154292  

#opencart_api_for_android #Opencart_rest_admin_api #opencart_rest_api #Rest_API_Integration #oc_rest_api #rest_api_ecommerce #rest_api_mobile #rest_api_opencart #rest_api_github #rest_api_documentation #opencart_rest_admin_api #rest_api_for_opencart_mobile_app #opencart_shopping_cart_rest_api #opencart_json_api

Unilevel MLM Wordpress Rest API FrontEnd | UMW Rest API Woocommerce

Unilevel MLM Wordpress Rest API FrontEnd | UMW Rest API Woocommerce Price USA, Philippines : Our API’s handle the Unilevel MLM woo-commerce end user all functionalities like customer login/register. You can request any type of information which is listed below, our API will provide you managed results for your all frontend needs, which will be useful for your applications like Mobile App etc.
Business to Customer REST API for Unilevel MLM Woo-Commerce will empower your Woo-commerce site with the most powerful Unilevel MLM Woo-Commerce REST API, you will be able to get and send data to your marketplace from other mobile apps or websites using HTTP Rest API request.
Our plugin is used JWT authentication for the authorization process.

REST API Unilevel MLM Woo-commerce plugin contains following APIs.
User Login Rest API
User Register Rest API
User Join Rest API
Get User info Rest API
Get Affiliate URL Rest API 
Get Downlines list Rest API
Get Bank Details Rest API
Save Bank Details Rest API
Get Genealogy JSON Rest API
Get Total Earning Rest API
Get Current Balance Rest API
Get Payout Details Rest API
Get Payout List Rest API
Get Commissions List Rest API
Withdrawal Request Rest API
Get Withdrawal List Rest API

If you want to know more information and any queries regarding Unilevel MLM Rest API Woocommerce WordPress Plugin, you can contact our experts through 
Skype: jks0586, 
Mail: letscmsdev@gmail.com,
Website: www.letscms.com, www.mlmtrees.com,
Call/WhatsApp/WeChat: +91-9717478599.  

more information : https://www.mlmtrees.com/product/unilevel-mlm-woocommerce-rest-api-addon

Visit Documentation : https://letscms.com/documents/umw_apis/umw-apis-addon-documentation.html

#Unilevel_MLM_WooCommerce_Rest_API's_Addon #umw_mlm_rest_api #rest_api_woocommerce_unilevel #rest_api_in_woocommerce #rest_api_woocommerce #rest_api_woocommerce_documentation #rest_api_woocommerce_php #api_rest_de_woocommerce #woocommerce_rest_api_in_android #woocommerce_rest_api_in_wordpress #Rest_API_Woocommerce_unilevel_mlm #wp_rest_api_woocommerce

A Simple Guide to Planning API Roadmaps

APIs - the current “big thing” - offer the opportunity for modern organizations to unlock new and lucrative business models. The article below covers some tips on how to spin the API flywheel and leverage its possibilities.

In the API economy, a successful service can gain popularity and be utilized in ways unpredicted and often inconceivable by its original owners. The very flexible nature of the technology opens many doors, including business collaborations, reuse in third-party products or even conquering hardware barriers by reaching a spectrum of devices.

What to consider

Taking the builder’s perspective

Important note: Most of the time API consumers are not the end-users but rather the app developers. Any new venture ought to be supported with excellent learning resources and descriptive documentation. These things combined will ensure a top-notch developer experience and encourage adoption of your product, increasing its visibility in the market.

More than the revenue

While in the simplest scenario, the most popular API business model is revenue via service charges, there are several other goals:

• **Growth **- APIs are finely-grained and, usually, short-term projects that bring lots of value. Decoupling sectors of your business and encapsulating them in the form of concise, dedicated APIs enable teams to work in parallel, encouraging company growth.
• **Reach **- By building APIs for wide use, the organization can extend its group of recipients and open new opportunities to cooperate with other players in the market and discover new collaborations.
• **Compliance **- Products and services implemented as an API ecosystem can freely exchange data between one another, whether they are internal or external.
• **Insight **- The rate of use of APIs will surely give an idea of what consumers value the most. Also, implementing APIs alone helps to clarify what pieces of your business are crucial. This helps to revise implementation details and encourages reflection of your current technological solutions.

#api #api-development #api-integration #restful-api #api-based-business-model #api-first-development #automation #rest-api