Use of coded values in the API calls and responses

[GUI]

Feedback from our API Usability Testing: Using less code values or more descriptive code values would make the APIs easier to use. An example of coded values can be seen in the alt fuel stations api. There you would pass in status=E for only open stations, which is not descriptive or intuitive. Something like status=open would be easier to understand. Some of our other code values might be slightly more descriptive, but they could definitely use improving (for example, in fuel types, CNG is a common abbreviation for compressed natural gas, but BD isn't necessarily as obvious for biodiesel).

[derekwmiller]

It also helps when the values listed in the API documentation match what is returned in the API.

For example, alt fuel stations in Oregon return the following unique values for 'groups_with_access_code':
Private - Government only
PLANNED - not yet accessible (Private)
Private
TEMPORARILY UNAVAILABLE (Public - Credit card at all times)
Public - Call ahead
Public - Credit card at all times
Public - Card key at all times
TEMPORARILY UNAVAILABLE (Public - Call ahead)
Public - Credit card after hours
PLANNED - not yet accessible (Public - Credit card at all times)
Public
Public - Card key after hours

Of those values, the following are not in the API doc and therefore unexpected in the return.
PLANNED - not yet accessible (Private)
TEMPORARILY UNAVAILABLE (Public - Credit card at all times)
TEMPORARILY UNAVAILABLE (Public - Call ahead)
PLANNED - not yet accessible (Public - Credit card at all times)

Also, case matters. The response and the docs don't match in regards to case (Public - Call ahead vs Public - call ahead)

Thanks.