Change log

From time to time, new platforms appear or are updated. RealFaviconGenerator evolves to be as up-to-date as possible. It is also updated to fix issues. These changes are listed in the change log. When using the API, it can be useful to access the change log programmatically in order to answer this basic question: was RealFaviconGenerator updated since the favicon was generated for the last time?

For example, suppose the API is used in May to generate a favicon. In June, a major change happens in RealFaviconGenerator: it is updated for the latest version of iOS. By asking RealFaviconGenerator for changes, you can discover this change and suggest your users to generate their favicons again.

Retrieve the changes by issuing a GET to https://realfavicongenerator.net/api/change-log. This entry point takes an optional parameter, since. This parameter must be an existing version. Usually, this parameter is populated with the version field returned by a favicon generation performed some time ago. For example, https://realfavicongenerator.net/api/change-log?since=0.5returns something like:

[
  {
    "version": "0.6",
    "date": "2014/02/11",
    "description": "(some human readable message here)",
    "importance": "Minor",
    "update_or_not": "(some human readable message here)",
    "relevance": {
      "automated_update": true,
      "manual_update": false
    }
  },
  {
    "version": "0.7",
    "date": "2014/04/16",
    "description": "(some human readable message here)",
    "importance": "Minor",
    "update_or_not": "(some human readable message here)",
    "relevance": {
      "automated_update": true,
      "manual_update": true
    }
  }
]

As a side effect, getting an empty document (ie. no element in the JSON array) means no change in RealFaviconGenerator since the last favicon generation.

Each update comes with a relevance section and two boolean attributes:

automated_update

Indicate if it makes sense to apply the update autmatically (ie. by running an existing non-interactive API request).

manual_update

Indicate if it makes sense to apply the update manually (ie. by prompting a human to visit RFG to generate the favion again or to edit an existing non-interactive API request).

To understand these attributes, let's consider three fictive updates:

• RFG now generates lighter icons. There is no visible change anywhere: the favicon editor remains the same, no new setting for the user to click. The non-interactive API is also unchanged. It's just that RFG creates 10% lighter pictures. In this example, automated_update istrue because running an existing non-interactive API request does take advantage of this update. But manual_update is false because a human intervention does not add any benefit.
• RFG now supports a new platform. There is a new section in the favicon editor and the non-interactive API was augmented accordingly. Here, manual_update is true because human intervention makes sense: a user can take design decision about this new platform, etc. Same for the non-interactive API: a developer can edit an existing request to generate stuff for this new platform.automated_update is false because running an existing non-ineractive API request as is does not add any value: it would generate the exact same set of icons and HTML code as before.
• The first two scenarios combined. RFG supports a new platform and all generated icons are 10% lighter. Here, both automated_update and manual_update are set to true.

The entry point also takes a format attribute, which can be set to html (default) or markdown. It can be used to choose the format of the humane readable content. For example, https://realfavicongenerator.net/api/change-log?since=0.5&format=markdown returns the same content as above, but the content is formatted in Markdown instead of HTML.