API Green Score

project

The API Green Score, a tool for more frugal APIs!

The way APIs are currently designed contributes to the digital pollution generated by the computer industry, accounting for 4% of greenhouse gas emissions!

It was, therefore, necessary to create a tool to reduce this impact. This is how the API Green Score was born.

The API Green Score is a toolbox intended for users, designers, and owners of APIs so that they can become aware of their environmental impact.

It consists of a best practice guide, encouraging concrete ecological transition, and an API evaluation grid.

Orignal document are available on "API Thinking collectif" website.

This tool is based on 7 differents domains in order to create relevant and realistic metrics that stakeholders can use.

The evaluation method is shared with all API Persona (API owners, API consumers, API developers)

We are talking about rules for the API Green Score Grid, but first, it's based on Best Practices.

/!\ Warning: this is still a very early stage project. Any feedback or contribution will be highly appreciated. Please refer to the contribution section.

This toolkit consists of an evaluation grid and evaluation rules.

But before using evaluation grid a short word about Best Practices.

For API we defined 7 Domains:

• API Lifecycle: Having a consumer repository. What is the impact of this repository on the API Green Score? Who consumes my API? What version? What is the number of requested calls compared to the number of calls? What is the date of the last call? What is the call volume?

• Data Exchange: Ensuring that APIs are eco-designed. How do we exchange data? What is the payload size? What type of message? What type of integration model? What is the call frequency? Cache frequency?

• Data: Understanding the use case and type of data involved. Expose only the necessary data, and data should be stored in a single point of truth. Data should be stored in a single and secure location.

• Architecture: How do I design my EDA + API integration flow? Which model is most suitable for a use case? Multicloud / Hybrid Cloud (private/public/OnPremise)?

• Tools: How can the API Gateway / technology / integration tools impact the data flow?

• Infrastructure: What is the distance between the API data center and the consumers/API backend? How many cloud providers, cloud services, DC locations are between the API consumer/API and the API backend? Is a scalable architecture used?

• Communication: How to share information about API use cases (CSR team, API owners, technical users)? Training?

To facilate the evaluation and fill the grid, we defined 4 categories, which can contains many domains, with many rules.

Each rules are associated to 1 of categories:

• Architecture (AR): Functional, technical archictures
• Design (DE): Directly linked to the definition of API
• Usage (US): The main point is how to use the API
• Log (LO) : how we keep trace of API usage?

API Lifecycle

• AR03 : Ensure Only One API fits same need
• US02 : Decommission EOL or unused APIs
• US03 : Limit the number of API versions
• US05 : Choose the correct API based on use case
• US06 : API well designed and documented to increase reuse rate
• US07 : Monitor Error Rate

Data exchange

• DE01 : Prefer smallest format for exchange (JSON instead of XML)
• DE02 : Use Cache
• DE03 : Use the cache efficiently to avoid useless resources consumption
• DE05 : Align Cache refresh strategy to data source
• DE07 : Is system, Business or CX API?
• DE08 : Implemented filtering mechanism to limit payload size
• DE11 : Availability of pagination
• US01 : Use query parameters for GET Methods

Data

• DE02 : Use Cache
• DE03 : Use the cache efficiently to avoid useless resources consumption
• DE06 : Allow a part cache refresh and align it on data refresh
• DE09 : Leverage OData or GraphQL when relevant
• US04 : Optimize queries to limit the information returned to - what is strictly necessary
• US05 : Choose the correct API based on use case
• USXX : Compressed Payload

Architecture

• AR01 : Use Event Driven Architecture
• AR02 : API Runtime close to the consumer
• AR03 : Ensure Only One API fits same need

Tools

• LO01 : Define log Retention Period (ops and legal)

Infrastructure

• AR04 : Use Scalable infra to avoid over-provisioning
• AR05 : Footprint dashboard of Cloud Provider

Communication

• US06 : API well designed and documented to increase reuse rate

Thanks a lot for your contribution!

Needs

Given the continuous advancements of API, this repository needs to be regularly updated. Any proposal or idea for improvement, modification, or deletion is welcome.

How to contribute?

Feel free to read the contributor's guide.

Shortcut to discussions:

To simplify your search, don't forget to use the available filters on the discussions page.

• :infinity: List of all discussions
• :heavy_plus_sign: List of discussions for adding rules
• :memo: List of discussions for modifying rules
• :heavy_multiplication_x: List of discussions for deleting rules

Licences

The sources and contents of this project are protected