# List of supported HTTP requests RepRapFirmware provides an HTTP interface for dealing with client requests. These requests are tailored for Duet Web Control in the first place but they may be used by third-party applications, too. Every request except for `rr_connect` returns HTTP status code `401` if the client does not have a valid session. If no machine password is set, a user session is created whenever an arbitrary HTTP request is made. Besides, RepRapFirmware may run short on memory and may not be able to respond properly. In this case, HTTP status code `503` is returned. In the following requests datetime strings may be used. These datetime strings are very similar to ISO8601-encoded strings but they do not contain timezone details. An example for such a string is `2019-12-13T21:27:00`. Make sure to follow this format where applicable. *Note: Starting from v3.4.1 there are OpenAPI definition files for [SBC](https://github.com/Duet3D/DuetSoftwareFramework/blob/v3.4-dev/OpenAPI.yaml) and [standalone](https://github.com/Duet3D/RepRapFirmware/blob/v3-chrishamm/Developer-documentation/OpenAPI.yaml) mode. If you are using .NET, check out the [DuetHttpClient](https://www.nuget.org/packages/DuetHttpClient/) package. If you want to explore the api using swagger, paste the .yaml file into : https://editor.swagger.io/* ## GET /rr_connect Attempt to create a new connection and log in using the (optional) password. Supported parameters: - `password` (optional): Machine password to log in with. If omitted, this defaults to `reprap` - `time` (optional): Current datetime that will be used to update RepRapFirmware's internal clock - `sessionKey` (optional): Either `yes` or `no`, if set to `yes`, RRF will generate a unique HTTP session (supported in RRF 3.5-b4 and later) Returns ``` { "err": code } ``` where `code` may be one of the following: - `0`: Password is valid and the client's IP address is added to the list of HTTP sessions - `1`: Password is invalid - `2`: No more user sessions available. This may occur when too many client devices are connected at the same time If the password is valid, extra fields are returned: ``` { "err": 0, "sessionTimeout": 8000, "boardType": "duetwifi102", "sessionKey": 123456 } ``` - `sessionTimeout` is the idle timeout in milliseconds before a client is removed again from the list of client sessions - `boardType` represents the board's type Officially supported board types are: | boardType | Board | Remarks | | --------- | ----- | ------- | | duet06 | Duet 0.6 | deprecated | | duet07 | Duet 0.7 | deprecated | | duet085 | Duet 0.8.5 | deprecated | | duetwifi10 | Duet WiFi v1.0 || | duetwifi102 | Duet WiFi v1.02 || | duetethernet10 | Duet Ethernet v1.0 || | duetethernet102 | Duet Ethernet v1.02 || | duetmaestro100 | Duet Maestro v1.0 || | duet3mb6hc100| Duet 3 MB6HC v0.6 and v1.0 || | duet3mb6hc101 | Duet 3 MB6HC v1.01 || | duet3mb6xd | Duet 3 MB6XD v1.0 || | duet5lcwifi | Duet 3 Mini 5+ WiFi || | duet5lcethernet | Duet 3 Mini 5+ Ethernet || ### HTTP Client: A HTTP Client is defined as a source IP address connecting to the HTTP Interface. If you have multiple applications that need to connect to the HTTP interface then they should be bound to a different IP address or use some other mechanism to manage replies. ### HTTP Sessions: Up to v3.5-b3 only one session per IP / HTTP Client is supported, further calls to rr_connect when an active session exists will be result in a "err" code of "0" returned but no additional session will be created. The same limitation applies if a client connects in 3.5-b4 and later if no `sessionKey` parameter with value `yes` is present. If a session key is used, the client must set the `X-Session-Key` header to the returned `sessionKey` value in all following HTTP requests in order to authenticate itself. Since IP-based sessions cannot keep the G-code reply for more than a single session per IP address, the usage of session keys is encouraged in v3.5-b4 and later. ### example /rr_connect ``` curl http://
/rr_connect?password= ``` ## GET /rr_disconnect Disconnect again from the RepRapFirmware controller. Returns ``` { "err": code } ``` where `code` may be `0` if the session could be removed, else it is `1`. ### example /rr_disconnect ``` curl http:///rr_disconnect ``` ## GET /rr_status (deprecated, scheduled for removal in RRF 3.6) Retrieve a status response from RepRapFirmware in JSON format. Deprecated in RRF 3.0 and later, use `rr_model` instead. Supported parameters: - `type`: Type of the status response The value of `type` can be one of: - 1: Standard status response - 2: Advanced status response. This also contains fields from the standard status response - 3: Print status response. This contains fields from the standard status response as well as information about the current (print) job See [JSON responses](https://github.com/Duet3D/RepRapFirmware/blob/v3-dev/JSON%20responses.md) for further information. ## Get /rr_config (deprecated, scheduled for removal in RRF 3.6) Retrieve the configuration response. This request provides a JSON object with values that are expected to change rarely. Deprecated in RRF 3.0 and later, use rr_model instead. See [JSON responses](https://github.com/Duet3D/RepRapFirmware/blob/v3-dev/JSON%20responses.md) for further information. ## GET /rr_gcode Execute arbitrary G/M/T-code(s). Supported parameters: - `gcode`: G/M/T-code to execute. This parameter must be present although it can be empty Returns ``` { "buff": bufferSpace } ``` where `bufferSpace` indicates how much buffer space for new G/M/T-codes is still available. If a file is supposed to be streamed over the HTTP interface, call this repeatedly and transfer only as many bytes as allowed. ### example /rr_gcode ``` curl http:///rr_connect?password= curl http:///rr_gcode?gcode=G28 ``` ## GET /rr_reply Retrieve the last G-code reply. The G-code reply is buffered per connected HTTP client and it is discarded when every HTTP client has fetched it or when the firmware is short on memory and the client has not requested it within reasonable time (1 second). Client should keep querying `rr_model?key=seqs` and monitor `seqs.reply`. When its value is incremented, that means there is new reply data available to fetch. The G-code reply is always returned as `text/plain`. ### example /rr_reply in this example we send the M115 gcode in order to generate a reply to fetch ``` curl http:///rr_connect?password= curl http:///rr_gcode?gcode=M115 curl http:///rr_reply ``` ## GET /rr_upload Get the last file upload result. Returns ``` { "err": code } ``` where `code` can be either `0` if the last upload successfully finished or `1` if an error occurred. ### example GET /rr_upload assuming sent immediately after a file upload ``` curl http:///rr_upload ``` ## POST /rr_upload Upload a file. Supported URL parameters: - `name`: Path to the file to upload - `time` (optional): ISO8601-like representation of the time the file was last modified - `crc32` (optional): CRC32 checksum of the file content as hex string *without* leading `0x`. Usage of this parameter is encouraged The raw HTTP body contains the file content. Binary file uploads are supported as well. Make sure to set `Content-Length` to the length of the HTTP body if your HTTP client does not already do that. Returns ``` { "err": code } ``` where `code` can be either `0` if the last upload successfully finished or `1` if an error occurred (e.g. CRC mismatch). ### example POST /rr_upload ``` curl http:///rr_connect?password= curl --data-binary @"