Skip to content

Latest commit

 

History

History
66 lines (48 loc) · 3.64 KB

http.adoc

File metadata and controls

66 lines (48 loc) · 3.64 KB
Raw

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 &. 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&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?