Vely application runs by processing requests. A request always takes form of an HTTP request, meaning a URL and an optional HTTP request body. This is regardless of whether it's a web or command line application.
A request name is always specified in the URL path. By default a request URL path is comprised of application name and request name, so it may look like:
http://<your website>/<app name>/<request name>?some_param=some_value...
for more details on the structure of a URL, and building_URL
on using URL in your application.
(a main Vely request dispatcher) uses request name to route the request to the appropriate function that handles it.
This handling is based on the names of .vely files, i.e. source code files that make up your project. The request name always matches the file name that handles it.
So for example, file "get_stock.vely" handles request "get_stock" by implementing a function "void get_stock()" in it. A request that is meant to call this function would have "/get_stock" in its URL path right after the application path (see request_URL
). The routing of this request to the namesake function will be done automatically by Vely. For instance, if application name is "stocks" and request name "get_stock", such request would be called by URL like:
Thus file "get_stock.vely" must implement a function "void get_stock()", and in the code below, it simply outputs text "Hello from get_stock: some_value":
@Hello from get_stock: <<p-out some_param>>
If the name of .vely file starts with an underscore ("_"), then it is a non_request
file and it will not handle a request. See how_vely_works
You can use hyphens in URLs and they are converted to underscore by Vely. So for example the above URL could be written with "get-stock" instead of "get_stock":
A request can have any number of input parameters, and based on them, perform any number of actions. A "request" generally refers to a combination of input parameters. Those requests that share the same request name but have different set of parameter names are its subrequests.