Endpoint return data does not match accepted request data

[jaredhendrickson13]

Currently, return data from API calls returns the internal XML data values which do not always match the request data parameters.

For example: say a client wanted to GET an existing firewall rule object to create a new object with the same values or slightly modified values. They could not simply use the return data as a payload for their POST request because the internal XML data returned from the GET request do not match the request parameters for a POST request.

This is not REST like. It would be preferred to have the API return data in the same representation it accepts as request data, and then have the backend translate the representation data into the internal values pfSense understands.

[jaredhendrickson13]

Small update to this since I've received a few duplicates of this issue. This occurs because pfSense only parses the XML configuration as strings and arrays of strings. This prevents values from returning in the format accepted by the API. Additionally, if updating or interacting with a stored object such as a PUT request to the /api/v1/firewall/rule endpoint, data processed/validated during the API call will be returned as the accepted format whereas the stored/untouched data will remain a string as parsed by pfSense. This creates mismatches in return data. An API representation component will need to be incorporated into the API framework to act as a translation piece between the pfSense expected/stored data and the API data.

This will be a very large change that is unlikely to happen anytime soon. For now, it is best to make your scripts aware of this issue and always check/convert data types when it is returned by the API and before any returned data is sent back to the API if they are needed as a specific type.