FXML3 Concerns

FlightAware AeroAPI
1

Good day,

I’ve been working on a C# REST API client for FXML3. I’ve run into several concerning issues that I would like the team’s feedback on.

  1. Pricing
    1. While I greatly appreciate the free tier, it’s difficult to properly codify all the endpoints due to some not being available for this tier.
    2. I understand having a request limit on a monthly basis, however, the queries per minute restriction makes integration testing nigh impossible. I can get around this by saving JSON of responses, but that hides any issues that may arise from the API changing.
    3. The pricing does seem extreme for open source development - could API keys be provided for open source developers via some sort of application?
  2. API Design
    1. Inconsistent naming conventions - Look at the “AirlineFlightSchedules” API, for instance, there are 3 different types of naming conventions in just the input parameters:
      image
    2. Inconsistent Responses - For most responses, I have to wrap the data that I care about in another class in order to actually access it due to the deserialization of the responses. This leads to code such as response.Results.Flights rather than just response.Flights. I can deal with this in the client’s code, but it seems unnecessary. Also, certain endpoints don’t need this, such as the ZipCodeInfo, which is what I expected across the board.
    3. Filters - This one I’m torn on. I understand that being able to apply a filter such as airline: {airline code} is nice. However, because ga is also available for endpoints such as AirportBoards, it makes it very difficult to provide proper typing information. Additionally, the FlightCancellationStatistics filters are interdependent, whereas the AirportBoards ones are not. This also feels inconsistent, but possibly is necessary.

Thank you for your time and consideration while reading this. I look forward to these points being addressed/answered.

2

Bump. I’m wondering if these issues are being discussed internally or if there are any updates on any of the concerns I mentioned?

Thank you.

3

There are no plans to drastically change the pricing model in a way that would allow unlimited free access or treat open source projects specially.

Argument and structure naming conventions are the result of many different internal and external legacy decisions, some which were made long ago and already have many other users depending on their current behavior. Perceived functional inconsistencies are sometimes a result of the different internal backend sources that are being used to provide the API. It is not always technically feasible to make these differences completely homogeneous in functionality.

4

Okay, thank you for your response.

The largest issue I have is the limit on number of queries per minute how that affects integration testing. I would expect everything to be increased by 100x to be realistic. Perhaps FlightAware has internal metrics that dispute this, however.