Skip to content

API-Green-Score/APIGreenScore

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

26 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

apigreenscore_logo

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.

License: GPL v3 Contributor Covenant


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

Data exchange

Data

Architecture

Tools

Infrastructure

Communication

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.

Licences

The sources and contents of this project are protected