# HTTP

This section shows how to make applications communicate using HTTP. For now, 4diac FORTE supports client http (get, put, post) and server (get). You should use the client and server FBs according to your needs. Publish and Subscribe blocks are currently not supported. All RDs and SDs data output/inputs should be connected to STRING types for it to work.

## 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

### Type of FB

- Only GET, PUT and POST are supported

- Needs a client FB

- For a GET request, it should have exactly 1 RD (where the output is stored). SDs are ignored

- For a PUT/POST request you can set the data to be sent in two ways:

  - On the PARAMETERS in the PARAM data input (see below)

  - In a RD (exactly 1) of the client FB
    If both cases are present, the RD takes precedence and the PARAMETER is ignored.

### PARAM

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

#### Mandatory

- `IP:PORT` → ip address and port of the remote endpoint

- `PATH` → path on the server to reach

- `POST | PUT | GET` → They should be written exactly like this, and they define the type of packet to be sent.

#### Optional

- `PARAMETERS:` parameters to be sent

- `content-type:` HTTP content-type of the packet to be sent. If parameters are used with PUT or POST (SD or PARAMETERS), content-type will be ignored and application/x-www-form-urlencoded will be used instead. If not defined, "text/html" will be used as default.

- `response-code:` the response that’s expected. If not defined, "HTTP/1.1 200 OK" will be used. If the response-code of a packet is not as defined, the packet is ignored. If "*" is set, the packet is never ignored, no matter what the response code is

#### Examples

- `http[34.231.219.193:80/get;GET;text/html;*]` → Accepts all responses

- `http[34.231.219.193:80/get?par1=value1;GET;text/html;*]` → Request with parameters

- `http[34.231.219.193:80/put;PUT;application/json]` → Use application/json content type

- `http[34.231.219.193:80/put;PUT;application/json;HTTP/1.1 201 Created]` → Use application/json content type and discard packets which have not "HTTP/1.1 201 Created" as response code

## Server

### Type of FB

- Only incoming GET requests are supported

- Needs a server FB

- It must have exactly one SD (for the response text)

- Can have 0 or many RDs for the incoming parameters

### PARAM

    http[PATH]

The server FB will trigger an event when the PATH is accessed with GET request. If parameters are provided, they should match the number of RDs in the FB 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 STRINGs.

## Notes

- The following IEC 61499 data types are currently NOT supported: DATE, DATE_AND_TIME, TIME_OF_DAY, arrays, structs

- By default, a GET request is sent as:

      GET /path HTTP/1.1
      Host: ip:port

- By default, a `PUT{POST}` request is sent as:

      PUT{POST} /path HTTP/1.1
      Host: ip:port
      Content-type: text/html
      Content-length: length_of_data_string

## 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