Generation

You can use the drogon_ctl command line tool to quickly generate custom controller class source files based on HttpController. The command format is as bellow:

  1. drogon_ctl create controller -h <[namespace::]class_name>

We create one controller class named User, under namespace demo v1:

  1. drogon_ctl create controller -h demo::v1::User

As you can see, two files have been added to the current directory, demo_v1_User.h and demo_v1_User.cc.

demo_v1_User.h is as follows:

  1. #pragma once
  3. #include <drogon/HttpController.h>
  5. using namespace drogon;
  7. namespace demo
  8. {
  9. namespace v1
  10. {
  11. class User : public drogon::HttpController<User>
  12. {
  13.   public:
  14.     METHOD_LIST_BEGIN
  15.     // use METHOD_ADD to add your custom processing function here;
  16.     // METHOD_ADD(User::get, "/{2}/{1}", Get); // path is /demo/v1/User/{arg2}/{arg1}
  17.     // METHOD_ADD(User::your_method_name, "/{1}/{2}/list", Get); // path is /demo/v1/User/{arg1}/{arg2}/list
  18.     // ADD_METHOD_TO(User::your_method_name, "/absolute/path/{1}/{2}/list", Get); // path is /absolute/path/{arg1}/{arg2}/list
  20.     METHOD_LIST_END
  21.     // your declaration of processing function maybe like this:
  22.     // void get(const HttpRequestPtr& req, std::function<void (const HttpResponsePtr &)> &&callback, int p1, std::string p2);
  23.     // void your_method_name(const HttpRequestPtr& req, std::function<void (const HttpResponsePtr &)> &&callback, double p1, int p2) const;
  24. };
  25. }
  26. }

demo_v1_User.cc is as follows:

  1. #include "demo_v1_User.h"
  3. using namespace demo::v1;
  5. // Add definition of your processing function here

Usage

Let’s edit the two files:

demo_v1_User.h is as follows:

  1. #pragma once
  3. #include <drogon/HttpController.h>
  5. using namespace drogon;
  7. namespace demo
  8. {
  9. namespace v1
  10. {
  11. class User : public drogon::HttpController<User>
  12. {
  13.   public:
  14.     METHOD_LIST_BEGIN
  15.     // use METHOD_ADD to add your custom processing function here;
  16.     METHOD_ADD(User::login,"/token?userId={1}&passwd={2}",Post);
  17.     METHOD_ADD(User::getInfo,"/{1}/info?token={2}",Get);
  18.     METHOD_LIST_END
  19.     // your declaration of processing function maybe like this:
  20.     void login(const HttpRequestPtr &req,
  21.                std::function<void (const HttpResponsePtr &)> &&callback,
  22.                std::string &&userId,
  23.                const std::string &password);
  24.     void getInfo(const HttpRequestPtr &req,
  25.                  std::function<void (const HttpResponsePtr &)> &&callback,
  26.                  std::string userId,
  27.                  const std::string &token) const;
  28. };
  29. }
  30. }

demo_v1_User.cc is as follows:

  1. #include "demo_v1_User.h"
  3. using namespace demo::v1;
  5. // Add definition of your processing function here
  7. void User::login(const HttpRequestPtr &req,
  8.                  std::function<void (const HttpResponsePtr &)> &&callback,
  9.                  std::string &&userId,
  10.                  const std::string &password)
  11. {
  12.     LOG_DEBUG<<"User "<<userId<<" login";
  13.     //Authentication algorithm, read database, verify, identify, etc...
  14.     //...
  15.     Json::Value ret;
  16.     ret["result"]="ok";
  17.     ret["token"]=drogon::utils::getUuid();
  18.     auto resp=HttpResponse::newHttpJsonResponse(ret);
  19.     callback(resp);
  20. }
  21. void User::getInfo(const HttpRequestPtr &req,
  22.                    std::function<void (const HttpResponsePtr &)> &&callback,
  23.                    std::string userId,
  24.                    const std::string &token) const
  25. {
  26.     LOG_DEBUG<<"User "<<userId<<" get his information";
  28.     //Verify the validity of the token, etc.
  29.     //Read the database or cache to get user information
  30.     Json::Value ret;
  31.     ret["result"]="ok";
  32.     ret["user_name"]="Jack";
  33.     ret["user_id"]=userId;
  34.     ret["gender"]=1;
  35.     auto resp=HttpResponse::newHttpJsonResponse(ret);
  36.     callback(resp);
  37. }

Each HttpController class can define many Http request handlers. Since the number of functions can be arbitrarily large, it is unrealistic to overload them with virtual functions. We need to register the handler itself (not the class) in the framework.

The mapping from the URL path to the handler is done by macros. You can add a multipath map with the METHOD_ADDmacro or the ADD_METHOD_TO macro. All METHOD_ADD and ADD_METHOD_TO statements should be sandwiched between the METHOD_LIST_BEGIN and METHOD_LIST_END macro statements.

The METHOD_ADD macro automatically prefixes the namespace and class name in the path map. Therefore, in this example, the login function is registered to the /demo/v1/user/token path, and the getInfo function is registered to the /demo/v1/user/xxx/info path. Constraints are similar to the PATH_ADD macro of HttpSimpleController and are not described here.

When you use the ADD_METHOD macro and the class belongs to some namespace, you should add that namespace to the access url. In this example, use http://localhost/demo/v1/user/token?userid=xxx&passwd=xxx or http://localhost/demo/v1/user/xxxxx/info?token=xxxx.

The ADD_METHOD_TO macro does almost as much as the former, except that it does not automatically add any prefixes, i.e. the path registered by the macro is an absolute path.

We see that HttpController provides a more flexible path mapping mechanism - we can put a class of functions in a class.

In addition, you can see that the macros provide a method for parameter mapping. We can map the query parameters on the path to the parameter list of the function. The number of URL path parameters corresponds to the function parameter’s position, this is very convenient. The common types which can be converted by string type all can be used as function parameters (such as std::string, int, float, double, etc.), and the drogon framework will automatically help you convert the type. This is very convenient for developing. Note that lvalue references must be of a const type.

The same path can be mapped multiple times, distinguished from each other by Http Method, which is legal and is a common practice of the Restful API, such as:

  1.  METHOD_LIST_BEGIN
  2.      METHOD_ADD(Book::getInfo,"/{1}?detail={2}",Get);
  3.      METHOD_ADD(Book::newBook,"/{1}",Post);
  4.      METHOD_ADD(Book::deleteOne,"/{1}",Delete);
  5.  METHOD_LIST_END

The placeholders of path parameters can be written in several ways:

  • {}: The position on the path is the position of the function parameter, which indicates that the path parameter maps to the corresponding position of the handler parameters.
  • {1},{2}: The path parameters with a number in them are mapped to the handler parameters specified by the number.
  • {anystring}: Strings here have no practical effect, but can improve the readability of the program. Equivalent to {}.
  • {1:anystring},{2:xxx}: The number before the colon represents the position. The string after the colon has no effect but can improve the readability of the program. Equivalent to the {1} and {2}.

The latter two are recommended, and if the path parameters and function parameters are in the same order, the third is enough. It is easy to see that the following are equivalent:

  • “/users/{}/books/{}”
  • “/users/{}/books/{2}”
  • “/users/{user_id}/books/{book_id}”
  • “/users/{1:user_id}/books/{2}”

Note: Path matching is not case sensitive, but parameter names are case sensitive. Parameter values ​​can be mixed in uppercase and lowercase and passed unchanged to the controller.

Parameter mapping

Through the previous description, we know that the parameters on the path and the query parameters after the question mark can be mapped to the parameter list of the handler function. The type of the target parameter needs to meet the following conditions:

  • Must be one of a value type, a constant left value reference, or a non-const right value reference. It cannot be a non-const lvalue reference. It is recommended to use an rvalue reference so that the user can dispose of it at will.

  • Basic types such as int, long, long long, unsigned long, unsigned long long, float, double, long double, etc can be used as parameter types.

  • std::string

  • Any type that can be assigned using the stringstream >> operator.

In addition, the drogon framework also provides a mapping mechanism from the HttpRequestPtr object to any type of parameter.. When the number of mapping parameters in your handler parameter list is more than the number of parameters on the path, the extra parameters will be converted by the HttpRequestPtr object. The user can define any type of conversion. The way to define this conversion is to specialize the fromRequest template (which is defined in the HttpRequest.h header file) in the drogon namespace, for example, say we need to make a RESTful interface to create a new user, we define the user’s structure as follows:

  1. namespace myapp{
  2. struct User{
  3.     std::string userName;
  4.     std::string email;
  5.     std::string address;
  6. };
  7. }
  8. namespace drogon
  9. {
  10. template <>
  11. inline myapp::User fromRequest(const HttpRequest &req)
  12. {
  13.     auto json = req.getJsonObject();
  14.     myapp::User user;
  15.     if(json)
  16.     {
  17.         user.userName = (*json)["name"].asString();
  18.         user.email = (*json)["email"].asString();
  19.         user.address = (*json)["address"].asString();
  20.     }
  21.     return user;
  22. }
  24. }

With the above definition and template specialization, we can define the path map and handler as follows:

  1. class UserController:public drogon::HttpController<UserController>
  2. {
  3. public:
  4.     METHOD_LIST_BEGIN
  5.         //use METHOD_ADD to add your custom processing function here;
  6.         ADD_METHOD_TO(UserController::newUser,"/users",Post);
  7.     METHOD_LIST_END
  8.     //your declaration of processing function maybe like this:
  9.     void newUser(const HttpRequestPtr &req,
  10.                  std::function<void (const HttpResponsePtr &)> &&callback,
  11.                  myapp::User &&pNewUser) const;
  12. };

It can be seen that the third parameter of myapp::User type has no corresponding placeholder on the mapping path, and the framework regards it as a parameter converted from the req object and obtains this parameter through the user-specialized function template. This is very convenient for users.

Further, some users do not need to access the HttpRequestPtr object except for their custom type data. They can put the custom object in the position of the first parameter, and the framework will correctly complete the mapping such as the above example. It can also be written as follows:

  1. class UserController:public drogon::HttpController<UserController>
  2. {
  3. public:
  4.     METHOD_LIST_BEGIN
  5.         //use METHOD_ADD to add your custom processing function here;
  6.         ADD_METHOD_TO(UserController::newUser,"/users",Post);
  7.     METHOD_LIST_END
  8.     //your declaration of processing function maybe like this:
  9.     void newUser(myapp::User &&pNewUser,
  10.                  std::function<void (const HttpResponsePtr &)> &&callback) const;
  11. };

Multiple Path Mapping

Drogon supports the use of regular expressions in path mapping, which can be used outside the ‘{}’ curly brackets. For example:

  1. ADD_METHOD_TO(UserController::handler1,"/users/.*",Post); /// Match any path prefixed with `/users/`
  2. ADD_METHOD_TO(UserController::handler2,"/{name}/[0-9]+",Post); ///Match any path composed with a name string and a number.

Regular Expressions

The above method has limited support for regular expressions. If users want to use regular expressions freely, drogon provides the ADD_METHOD_VIA_REGEX macro to achieve this, such as:

  1. ADD_METHOD_VIA_REGEX(UserController::handler1,"/users/(.*)",Post); /// Match any path prefixed with `/users/` and map the rest of the path to a parameter of the handler1.
  2. ADD_METHOD_VIA_REGEX(UserController::handler2,"/.*([0-9]*)",Post); /// Match any path that ends in a number and map that number to a parameter of the handler2.
  3. ADD_METHOD_VIA_REGEX(UserController::handler3,"/(?!data).*",Post); /// Match any path that does not start with '/data'

As can be seen, parameter mapping can also be done using regular expressions, and all strings matched by subexpressions will be mapped to the parameters of the handler in order.

It should be noted that when using regular expressions, you should pay attention to matching conflicts (multiple different handlers are matched). When conflicts happen in the same controller, drogon will only execute the first handler (the one registered in the framework first). When conflicts happen between different controllers, it is uncertain which handler will be executed. Therefore, users need to avoid these conflicts.

04.3 WebSocketController