# This header is for providing additional information to hugo for the website generation it ignored by asciidoctor

title: "HTTP" url: doc/communication/http.html page_css_file: /4diac/css/4diac_doc.css sidebar: - sb-doc ---

# HTTP

This section shows how to make applications communicate using the HTTP protocol. You should use the client and server FBs according to your needs. Publish and Subscribe blocks are currently not supported. Currently only `GET`, `POST` or `PUT` requests are supported.

## Configuration

4diac Forte must be compiled from source code for the HTTP module to work. Follow the steps to build your own FBs. In the step 3 where the features to be compiled are selected, select also `FORTE_COM_HTTP`. Then follow the same procedure, compile 4diac FORTE, et voilà, you have HTTP support on your 4diac FORTE.

## Client

To realize an HTTP client, a client function block is needed with 3 SD inputs and 2 RD outputs, otherwise the runtime should log an error. The SDs are expected to be of type `STRING` or `WSTRING`, whereas the RDs are expected to be of type `STRING`. Currently only GET, PUT and POST are supported. The ID input of the client function block should be specified as follows:

    http[IP:PORT/PATH;POST|PUT|GET;content-type]

The `IP:PORT` specifies the IP address and the port of the remote endpoint. The `PATH` specifies the path on the server to reach and is separated from the port by a slash. As request type `POST` or `PUT` or `GET` can be used, and should be written written in capital letters. The request type is mandatory. The `content-type` represents the HTTP content-type of the packet to be sent, but is optional. Default `content-type` is `text/html`. Examples for the ID input are the following:

- `http[34.231.219.193:80/get;GET;text/html]` → send GET request with text/html content type

- `http[34.231.219.193:80/put;PUT;application/json]` → send PUT request, with application/json content type

The first SD can be used for authentication, but can also be left empty in case the corresponding server does not require this. The second SD can be used for parameters, where the parameters should be separated by the HTML representation for &, which is `&amp;`. This second SD can also be left empty when no parameters are needed. The third SD input is used for the body, that is supposed to be sent. Examples for the three SD inputs are as follows:

- authentication: `Token enterTheTokenProvidedByTheServerHere`

- parameters: `org=organization&amp;bucket=sensors`

- body: `airSensors,sensor_id=TLM0201 temperature=73.97038159354763,humidity=35.23103248356096,co=0.48445310567793615`

Both RDs are used for the server’s response. The first RD is used for the response code, whereas the second RD is used for the body of the server’s response.

## Server

To realize an HTTP server, a server function block is needed with 1 SD input for the body of the response it creates. The SD input expects type `STRING` or `WSTRING`. The ID input of the server function block should be specified as follows:

    http[PATH]

The specified `PATH` is added to the server at startup. The server FB will trigger an event when the `PATH` is accessed with a GET request. Server responses use HTTP version `HTTP/1.1` and content-type `text/plain` as default. If parameters are provided, they should match the number of RDs of the function block and should be of type (name=value&…​.). The "&" should be used to define more than one parameter. The name is actually not used. The values are stored in the RDs in the order they arrived and treated as `STRING` values.

## Where to go from here?

- Go back to Protocols index:
  Communication Index

- If you want to go back to the Start Here page, we leave you here a fast access:
  Start Here page

Or Go to top