├── .gitignore ├── CONTRIBUTING.md ├── LICENCE.md ├── README.md ├── chapters ├── AR01_en.md ├── AR02_en.md ├── AR03_en.md ├── AR04_en.md ├── AR05_en.md ├── DE01_en.md ├── DE02_en.md ├── DE03_en.md ├── DE04_en.md ├── DE05_en.md ├── DE06_en.md ├── DE07_en.md ├── DE08_en.md ├── DE09_en.md ├── DE10_en.md ├── DE11_en.md ├── LO01_en.md ├── US01_en.md ├── US02_en.md ├── US03_en.md ├── US04_en.md ├── US05_en.md ├── US06_en.md └── US07_en.md └── resources ├── APIGreenScore.ico ├── APIGreenScore_logo.png ├── YYxx_en.md └── apigreenscore_logo_byCAT.png /.gitignore: -------------------------------------------------------------------------------- 1 | # Ignore all files and folders starting with ".", except a few exceptions 2 | .* 3 | !.gitignore 4 | !.gitattributes 5 | !.github/ 6 | 7 | # Ignore generated files 8 | target 9 | lib 10 | bin 11 | dependency-reduced-pom.xml 12 | 13 | # Ignore IDE files 14 | *.iml 15 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing to the Best Practices Repository 2 | Anyone who wishes to can propose contributions to the repository. 3 | 4 | The rules of this document must be respected. 5 | 6 | The project team in charge of this repository ensures compliance with these rules. 7 | 8 | # Purpose of Contributions 9 | Contributions aim to: 10 | 11 | - Remove outdated, inapplicable, or ineffective best practices. 12 | - Add relevant best practices based on practical experience. 13 | - Associate compliance rules with new best practices. 14 | - Verify and improve existing best practices and their compliance rules if necessary. 15 | - Propose any ideas that could enhance the repository in general and, if appropriate, implement them. 16 | 17 | # General Rules 18 | - Everyone has a place, and everyone can contribute their experience. 19 | - Friendliness, sharing, courtesy, and kindness are golden rules in interactions. 20 | - Each best practice should be based on field feedback or scientific approaches. 21 | - These best practices also serve as a memory aid, so even a simple, common-sense best practice can have its place. 22 | 23 | 24 | ## ProjectTeam 25 | 26 | The project team consists of: 27 | 28 | - [Yannick Tremblais](https://github.com/ytremblais) 29 | - [Julien Brun] () 30 | - [Liliana Jena] () 31 | - [Christelle Ravaudet] () 32 | - [Julien Bichon] () 33 | - [David De Carvalho](https://github.com/dedece35) 34 | 35 | 36 | The project team ensures that the established rules for contribution are respected. 37 | 38 | In the event of disagreements among contributors, their role is to make final decisions. 39 | 40 | The project team demonstrates transparency and strives for decisions to be as collective as possible. 41 | 42 | The project team is responsible for the definitive validation of `Pull Requests` and the integration of proposed additions, modifications, or deletions into the repository. 43 | 44 | A member of the project team can submit a proposal to the contributors but cannot be solely responsible for approving or rejecting it: a consensus from the project team is required. 45 | 46 | 47 | 48 | ## Proposal 49 | 50 | Every proposal for adding, major modification, or deletion of best practices must go through [a discussion](https://github.com/API-Green-Score/APIGreenScore/discussions/categories/bonnes-pratiques). 51 | 52 | The title of the discussion should be explicit and specify whether it is an addition, a major modification, or a deletion. 53 | 54 | A major modification may include: 55 | 56 | Significant changes to the priority level, i.e., implementation levels and ecological impacts. 57 | - Addition or removal of elements in the rule definition. 58 | - Addition or removal of examples. 59 | - Modification of the compliance rule. 60 | 61 | Any contributor can express their opinion on the proposal: 62 | 63 | - In case of agreement, a contributor can click the "thumbs up" icon. 64 | - In case of disagreement, a contributor can add a "thumbs down" icon and must provide an explanation in a comment. 65 | - In case of confusion, a contributor can initiate a discussion to seek clarification. 66 | - If there are ideas for improvement, they can be proposed. 67 | 68 | When a proposal receives multiple positive votes, the project team is notified and evaluates the relevance of the best practice. 69 | 70 | The following scenarios may occur: 71 | 72 | - The proposal is approved, and the contributor can create an Issue referencing the discussion. 73 | - The proposal is definitively rejected with justification. 74 | - The proposal needs to be reworked before a final decision is made 75 | 76 | The created `Issue` should include the tag `create`, `modify`, or `delete` depending on the type of proposal and should be linked to the [`Best Pratices project`](https://github.com/API-Green-Score/APIGreenScore/projects/1). 77 | 78 | For additions, the file should be named following the pattern: `YYxx_en.md`, where ̀`YY` means category an `xx` is the number assigned to the rules by the project team. 79 | 80 | The file should be copied from the [template](./resources/YYxx_en.md). 81 | 82 | A `Pull Request` associated ton `Issue` will be created and submitted to the project team for review. 83 | 84 | The creation of a `Pull Request` follows the standard process within GitHub, which includes: 85 | 86 | - Creating a personal `fork` by the person in charge of the `Pull Request`. 87 | - Adding the original repository as a remote (`upstream`). 88 | - Creating a branch on the personal fork. 89 | - Creating a `Pull Request` from the fork, with the target branch set to the `main` branch of the target repository. 90 | 91 | 92 | # Improvement 93 | 94 | For improvements such as: 95 | 96 | - Spelling, grammar, or conjugation corrections 97 | - Alternative wording 98 | - Formatting changes 99 | 100 | There is no need to go through a discussion. The following steps should be taken: 101 | 102 | - Create an `Issue` with a clear title and the tags `modify` and `minor`. 103 | - Develop and create the associated PR, making sure to reference the `Issue`. 104 | 105 | ## Content of a Best Practice 106 | 107 | Each best practice must include the following: 108 | 109 | - Title 110 | - Priority level (on a scale of 5, where 5 is highest priority and 1 is lowest) 111 | - Implementation difficulty (on a scale of 5, where 5 is easiest and 1 is most difficult) 112 | - Ecological impact level (on a scale of 5, where 5 has the highest impact and 1 has the lowest) 113 | - Description 114 | - Validation rule and compliance threshold 115 | 116 | The following elements are optional: 117 | 118 | - One or more examples 119 | - Alternative solution 120 | 121 | ### Validation Rule and Compliance Threshold 122 | 123 | The validation rule allows for testing the implementation of the best practice using an objective approach. 124 | The compliance threshold associates a numeric value (threshold) with the validation rule, allowing for a binary decision (yes/no) on whether the best practice has been implemented or not. 125 | The set of validation rules and compliance thresholds establishes the level of maturity achieved by the digital service. 126 | 127 | 128 | ### Definition of Levels 129 | 130 | Three levels need to be defined for a best practice: 131 | 132 | 1. Implementation (ease or difficulty of implementing the best practice) 133 | 2. Environmental impacts (contribution to reducing environmental impacts) 134 | 3. Priority (this level is determined based on 1 and 2) 135 | 136 | Each of these levels is defined by a rating from 1 to 5. 137 | 138 | #### Implementation (higher is better) 139 | 140 | The ease or difficulty of implementation can be evaluated as follows: 141 | 142 | 1. Implementation requires a high level of expertise and a major project overhaul. 143 | 2. Implementation requires a high level of expertise or a major project overhaul. 144 | 3. Implementation requires a specific skill without being rare (e.g., SEO, DBA, ...) and does not require a major project overhaul. 145 | 4. Implementation does not require a specific skill or have side effects on the rest of the project. 146 | 5. Implementation does not require a specific skill and has no side effects on the rest of the project. 147 | 148 | #### Environmental Impact (higher is better) 149 | 150 | The contribution can be evaluated as follows: 151 | 152 | 1. It reduces the impact of networks 153 | 2. It reduces the impact of compute 154 | 3. It reduces the impact of storage 155 | 156 | #### Priority (higher is better) 157 | 158 | The priority level is freely proposed by the contributor and is based on the Implementation and Environmental Impact. 159 | -------------------------------------------------------------------------------- /LICENCE.md: -------------------------------------------------------------------------------- 1 | # Licence CC-By-NC-ND 2 | 3 | You are obligated to transmit the titles and validation rules of all the best practices from version 1 as is, without modification, in its entirety, including the information below: 4 | 5 | The "API Green Score Repository (AGSR)" is published by the API Thinking Collective as part of the work of the Responsible Digital Design Collective under the terms of the Creative Commons Attribution-NonCommercial-NoDerivatives 1.0 International License. 6 | 7 | This work, creation, website, or text is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License. To access a copy of this license, please visit the following address: https://creativecommons.org/licenses/by-nc-nd/4.0/ or send a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA. 8 | 9 | ## Usage 10 | 11 | The titles and contents of the best practices from version 1 are published under the Creative Commons BY-NC-ND license. This means that you can freely use it for non-commercial purposes, on the condition of maintaining the authorship of the content, via a link to [https://www.collectif](https://www.collectif-api-thinking.com/). 12 | 13 | ## Title 14 | 15 | API Green Score Repository (AGSR) 16 | 17 | Main Author: API Thinking Collective 18 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ![apigreenscore_logo](resources/apigreenscore_logo_byCAT.png) 2 | ============================= 3 | # API Green Score 4 | 5 | ## project 6 | 7 | The API Green Score, a tool for more frugal APIs! 8 | 9 | The way APIs are currently designed contributes to the digital pollution generated by the computer industry, accounting for 4% of greenhouse gas emissions! 10 | 11 | It was, therefore, necessary to create a tool to reduce this impact. This is how the API Green Score was born. 12 | 13 | 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. 14 | 15 | It consists of a [best practice guide](https://www.collectif-api-thinking.com/assets/deliverables/worksites/50_CAT_API_Sustainable_IT.pdf), encouraging concrete ecological transition, and [an API evaluation grid](https://www.collectif-api-thinking.com/assets/deliverables/worksites/48_CAT_Sustainable_API_GreenScore_V1-2.xlsx). 16 | 17 | Orignal document are available on ["API Thinking collectif"](https://www.collectif-api-thinking.com/ ) website. 18 | 19 | This tool is based on 7 differents domains in order to create relevant and realistic metrics that stakeholders can use. 20 | 21 | The evaluation method is shared with all API Persona (API owners, API consumers, API developers) 22 | 23 | We are talking about rules for the API Green Score Grid, but first, it's based on Best Practices. 24 | 25 | **/!\ Warning**: this is still a very early stage project. Any feedback or contribution will be highly appreciated. Please 26 | refer to the contribution section. 27 | 28 | [![License: GPL v3](https://img.shields.io/badge/License-GPLv3-blue.svg)](https://www.gnu.org/licenses/gpl-3.0) 29 | [![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.1-4baaaa.svg)](https://github.com/green-code-initiative/ecoCode-common/blob/main/doc/CODE_OF_CONDUCT.md) 30 | 31 | -------------------- 32 | 33 | This toolkit consists of an evaluation grid and evaluation rules. 34 | 35 | But before using evaluation grid a short word about Best Practices. 36 | 37 | For API we defined 7 Domains: 38 | 39 | - **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? 40 | 41 | - **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? 42 | 43 | - **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. 44 | 45 | - **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)? 46 | 47 | - **Tools**: How can the API Gateway / technology / integration tools impact the data flow? 48 | 49 | - **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? 50 | 51 | - **Communication**: How to share information about API use cases (CSR team, API owners, technical users)? Training? 52 | 53 | To facilate the evaluation and fill the grid, we defined 4 categories, which can contains many domains, with many rules. 54 | 55 | 56 | Each rules are associated to 1 of categories: 57 | 58 | - **Architecture (AR)**: Functional, technical archictures 59 | - **Design (DE)**: Directly linked to the definition of API 60 | - **Usage (US)**: The main point is how to use the API 61 | - **Log (LO)** : how we keep trace of API usage? 62 | 63 | 64 | ### API Lifecycle 65 | - [AR03 : Ensure Only One API fits same need](/chapters/AR03_en.md) 66 | - [US02 : Decommission EOL or unused APIs](/chapters/US02_en.md) 67 | - [US03 : Limit the number of API versions](/chapters/US03_en.md) 68 | - [US05 : Choose the correct API based on use case](/chapters/US05_en.md) 69 | - [US06 : API well designed and documented to increase reuse rate](/chapters/US06_en.md) 70 | - [US07 : Monitor Error Rate](/chapters/US07_en.md) 71 | 72 | ### Data exchange 73 | - [DE01 : Prefer smallest format for exchange (JSON instead of XML)](/chapters/DE01_en.md) 74 | - [DE02 : Use Cache](/chapters/DE02_en.md) 75 | - [DE03 : Use the cache efficiently to avoid useless resources consumption](/chapters/DE03_en.md) 76 | - [DE05 : Align Cache refresh strategy to data source](/chapters/DE05_en.md) 77 | - [DE07 : Is system, Business or CX API?](/chapters/DE07_en.md) 78 | - [DE08 : Implemented filtering mechanism to limit payload size](/chapters/DE08_en.md) 79 | - [DE11 : Availability of pagination](/chapters/DE11_en.md) 80 | - [US01 : Use query parameters for GET Methods](/chapters/US01_en.md) 81 | 82 | ### Data 83 | - [DE02 : Use Cache](/chapters/DE02_en.md) 84 | - [DE03 : Use the cache efficiently to avoid useless resources consumption](/chapters/DE03_en.md) 85 | - [DE06 : Allow a part cache refresh and align it on data refresh](/chapters/DE06_en.md) 86 | - [DE09 : Leverage OData or GraphQL when relevant](/chapters/D09_en.md) 87 | - [US04 : Optimize queries to limit the information returned to - what is strictly necessary](/chapters/US04_en.md) 88 | - [US05 : Choose the correct API based on use case](/chapters/US05_en.md) 89 | - [USXX : Compressed Payload](/chapters/USxx_en.md) 90 | 91 | ### Architecture 92 | - [AR01 : Use Event Driven Architecture](/chapters/AR01_en.md) 93 | - [AR02 : API Runtime close to the consumer](/chapters/AR02_en.md) 94 | - [AR03 : Ensure Only One API fits same need](/chapters/AR03_en.md) 95 | 96 | 97 | ### Tools 98 | - [LO01 : Define log Retention Period (ops and legal)](/chapters/LO01_en.md) 99 | 100 | ### Infrastructure 101 | - [AR04 : Use Scalable infra to avoid over-provisioning](/chapters/AR04_en.md) 102 | - [AR05 : Footprint dashboard of Cloud Provider](/chapters/AR05_en.md) 103 | 104 | ### Communication 105 | - [US06 : API well designed and documented to increase reuse rate](/chapters/US06_en.md) 106 | 107 | 108 | Thanks a lot for your contribution! 109 | 110 | 111 | ## Needs 112 | 113 | Given the continuous advancements of API, this repository needs to be regularly updated. 114 | Any proposal or idea for improvement, modification, or deletion is welcome. 115 | 116 | ## How to contribute? 117 | 118 | Feel free to read [the contributor's guide](CONTRIBUTING.md). 119 | 120 | ## Shortcut to discussions: 121 | 122 | To simplify your search, don't forget to use the available filters on the discussions page. 123 | 124 | - :infinity: [List of all discussions](https://github.com/API-Green-Score/APIGreenScore/discussions) 125 | - :heavy_plus_sign: [List of discussions for adding rules](https://github.com/API-Green-Score/APIGreenScore/discussions?discussions_q=label%3Aaddition) 126 | - :memo: [List of discussions for modifying rules](https://github.com/API-Green-Score/APIGreenScore/discussions?discussions_q=label%3Amodification) 127 | - :heavy_multiplication_x: [List of discussions for deleting rules](https://github.com/API-Green-Score/APIGreenScore/discussions?discussions_q=label%3Adeletion) 128 | 129 | 130 | ## Licences 131 | 132 | The sources and contents of this project are [protected](LICENCE.md) 133 | -------------------------------------------------------------------------------- /chapters/AR01_en.md: -------------------------------------------------------------------------------- 1 | ## Use Event Driven Architecture to avoid polling madness 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | AR01 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Architecture | Network/Compute | API Producer/API Consumer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / compute / storage | 24 | 25 | ### Description 26 | 27 | We often notice that applications, in order to refresh their data, make very frequent requests to APIs. 28 | This causes an important workload and we increase the computing resources to absorb this load in order not to penalize the other users. 29 | 30 | The best practice is to use an event-driven architecture in order to receive a notification when a piece of information is modified to avoid making regular useless requests. But the data contained in the event must be precise to be sure to avoid a system making a request to retrieve an unused data. 31 | 32 | 33 | 34 | ### Example 35 | TBD 36 | 37 | ### Validation principle 38 | 39 | true of false -------------------------------------------------------------------------------- /chapters/AR02_en.md: -------------------------------------------------------------------------------- 1 | ## AR02 : API Runtime close to the consumer 2 | 3 | 4 | ### Identifiers 5 | 6 | | API Green Score | V1 | V2 | V3 | 7 | |:-------:|:----:|:----:|:----:| 8 | | AR02 | 1 | | | 9 | 10 | ### Categories 11 | 12 | | Lifecycle | Resources | Responsible | 13 | |:---------:|:----:|:----:| 14 | | Architecture | Network | API Producer | 15 | 16 | ### Indications 17 | 18 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 19 | |:-------------------:|:-------------------------:|:---------------------:| 20 | | tbd | tbd | tbd | 21 | 22 | |Saving Resources | 23 | |:----------------------------------------------------------:| 24 | |network | 25 | 26 | ### Description 27 | 28 | It is not uncommon to find that APIs are deployed in locations that are not selected in relation to their consumers. 29 | 30 | This results in not only a degraded user experience in some cases, but also a greater demand on the network to route requests sometimes to a region on the other side of the world. 31 | 32 | Good architecture practices therefore recommend deploying APIs, and services in general, as close as possible to the consumers. Also, if possible, prefer a deployment in several locations with geo routing (aka. position based routing) to the closest instance to improve response times and reduce the number of kilometers traveled by requests. 33 | 34 | 35 | 36 | ### Example 37 | TBD 38 | 39 | ### Validation principle 40 | 41 | true of false -------------------------------------------------------------------------------- /chapters/AR03_en.md: -------------------------------------------------------------------------------- 1 | ## Ensure Only One API fits same need 2 | ### Identifiers 3 | 4 | | API Green Score | V1 | V2 | V3 | 5 | |:-------:|:----:|:----:|:----:| 6 | | AR03 | 1 | | | 7 | 8 | ### Categories 9 | 10 | | Lifecycle | Resources | Responsible | 11 | |:---------:|:----:|:----:| 12 | | Architecture | Compute | API Producer | 13 | 14 | ### Indications 15 | 16 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 17 | |:-------------------:|:-------------------------:|:---------------------:| 18 | | tbd | tbd | tbd | 19 | 20 | |Saving Resources | 21 | |:----------------------------------------------------------:| 22 | | compute | 23 | 24 | ### Description 25 | 26 | It is often noticed, especially in large information systems, that an API with the same purpose and objective can exist several times. 27 | 28 | These duplicate APIs, in addition to creating confusion in the minds of users, consume additional resources instead of pooling them for a unique API. 29 | 30 | It is recommended to use the data catalog to make sure that the API you want to develop does not already exist. If an existing API covers part of the functional scope, it may be worthwhile to contact the producer as it may be possible to plan an evolution of the existing system rather than creating a duplicate. 31 | 32 | 33 | ### Example 34 | TBD 35 | 36 | ### Validation principle 37 | 38 | true of false -------------------------------------------------------------------------------- /chapters/AR04_en.md: -------------------------------------------------------------------------------- 1 | ## Use scalable infrastructure to avoid over-provisioning 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | AR04 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Architecture | Network/Compute | API Producer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | | network/compute | 24 | 25 | ### Description 26 | 27 | Depending of your infrastructure, used scalable runtime fit to your activity 28 | 29 | 30 | 31 | 32 | ### Example 33 | Docker EE, Kubernetes as a best way to scale up or scale Down depending of season activities 34 | 35 | ### Validation principle 36 | 37 | true of false -------------------------------------------------------------------------------- /chapters/AR05_en.md: -------------------------------------------------------------------------------- 1 | ## Carbon Footprint Dashboard 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | AR05 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Architecture | Network/Compute | API Producer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | | network/compute | 24 | 25 | ### Description 26 | 27 | Some cloud providers produce carbon footprint dashboards. You can implement your own or adapt it based on your infrastructure to be close to your usage. 28 | 29 | This is not a rule to evaluate API Green score, but it is important to be able to measure the impact on infrastructure 30 | 31 | 32 | 33 | ### Example 34 | evaluation of the impact of computing, network and disk divided by the number of calls of the evaluated API. 35 | 36 | ### Validation principle 37 | 38 | true of false -------------------------------------------------------------------------------- /chapters/DE01_en.md: -------------------------------------------------------------------------------- 1 | ## Prefer smallest format for exchange (JSON instead of XML) 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | DE01 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Design | Network/Compute/Storage | API Producer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / compute / storage | 24 | 25 | ### Description 26 | 27 | One of the structuring questions when designing an API is the selection of the exchange format to use. If the choice is often made by technical constraints or personal affinities, the durability aspect is also to be taken into account. 28 | 29 | Indeed, there are exchange formats that are heavier than others. For example, JSON is smaller than XML. The second format will therefore have a stronger impact on the network, the computing and the storage. 30 | 31 | In the interest of sustainability, we recommend to use a lighter exchange format to reduce the bandwidth consumed for the requests, the compute and storage resources consumption used to process and store the payloads. 32 | 33 | ### Example 34 | For instance, this HTTP request `GET https://openlibrary.org/search.json?q=harry potter` returns a JSON value. We can convert it to XML and compare the sizes. 35 | 36 | ```java 37 | String responseBody = new RestTemplate().getForEntity(url, String.class).getBody(); 38 | 39 | ObjectMapper objectMapper = new ObjectMapper(); 40 | JsonNode jsonNode = objectMapper.readTree(responseBody); 41 | 42 | String xmlValue = new XmlMapper().writeValueAsString(jsonNode); 43 | xmlPayloadSize = xmlValue.getBytes().length; 44 | 45 | // since the XML serialized value does not contain indentation, 46 | // we also re-serialize the JSON value without indentation 47 | // so it is a fair comparison. 48 | String jsonValue = objectMapper.writeValueAsString(jsonNode); 49 | jsonPayloadSize = jsonValue.getBytes().length; 50 | ``` 51 | 52 | Here is the result: 53 | ```json 54 | { 55 | "url": "https://openlibrary.org/search.json?q=harry potter", 56 | "jsonPayloadSize": 40702, 57 | "xmlPayloadSize": 58332 58 | } 59 | ``` 60 | By using XML, there is 18kB increase (43% !). 61 | 62 | On an endpoint requested 1 million times per day, it represents 18GB that are "useless". 63 | 64 | ### Validation principle 65 | 66 | true of false 67 | -------------------------------------------------------------------------------- /chapters/DE02_en.md: -------------------------------------------------------------------------------- 1 | ## Use cache to avoid useless requests and preserve compute resources. 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | DE02 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Design | Network/Compute/Storage | API Producer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / compute / storage | 24 | 25 | ### Description 26 | 27 | The use of a cache has become common in computer architectures to store frequently used information on a fast storage. 28 | 29 | In addition to improving the response time of APIs, and therefore the consumer's experience of the service, it also saves computational resources by avoiding executing the same query on the same data multiple times. 30 | 31 | It is recommended to place a cache in front of each brick of an architecture returning data (API, database, frontend application, ...) and close to the users to preserve compute resources and improve performances of the API. 32 | 33 | 34 | 35 | ### Example 36 | TBD 37 | 38 | ### Validation principle 39 | 40 | true of false -------------------------------------------------------------------------------- /chapters/DE03_en.md: -------------------------------------------------------------------------------- 1 | ## Use cache to avoid useless requests and preserve compute resources. 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | DE03 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Design | Network/Compute/Storage | API Producer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / compute / storage | 24 | 25 | ### Description 26 | 27 | The use of a cache has become common in computer architectures to store frequently used information on a fast storage. 28 | 29 | In addition to improving the response time of APIs, and therefore the consumer's experience of the service, it also saves computational resources by avoiding executing the same query on the same data multiple times. 30 | 31 | It is recommended to place a cache in front of each brick of an architecture returning data (API, database, frontend application, ...) and close to the users to preserve compute resources and improve performances of the API. 32 | 33 | 34 | 35 | ### Example 36 | TBD 37 | 38 | ### Validation principle 39 | 40 | true of false -------------------------------------------------------------------------------- /chapters/DE04_en.md: -------------------------------------------------------------------------------- 1 | ## Prefer opaque token prior to JWT 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | DE04 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Design | Network/Compute/Storage | API Producer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / compute / storage | 24 | 25 | ### Description 26 | 27 | One of the structuring questions when designing an API is the selection of the token type to use. If the choice is often made by technical constraints or personal affinities, the durability aspect is also to be taken into account. 28 | 29 | We can note that an opaque token, in addition to improve the security, is smaller than a JWT token which will have a stronger impact on the network, storage and compute resources. 30 | In the interest of sustainability, it is therefore recommended that a lighter token type be preferred in order to reduce the bandwidth, compute and storage resources consumption. 31 | 32 | 33 | 34 | 35 | ### Example 36 | TBD 37 | 38 | ### Validation principle 39 | 40 | true of false -------------------------------------------------------------------------------- /chapters/DE05_en.md: -------------------------------------------------------------------------------- 1 | ## Use cache to avoid useless requests and preserve compute resources. 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | DE05 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Design | Network/Compute/Storage | API Producer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / compute / storage | 24 | 25 | ### Description 26 | 27 | The use of a cache has become common in computer architectures to store frequently used information on a fast storage. 28 | 29 | In addition to improving the response time of APIs, and therefore the consumer's experience of the service, it also saves computational resources by avoiding executing the same query on the same data multiple times. 30 | 31 | It is recommended to place a cache in front of each brick of an architecture returning data (API, database, frontend application, ...) and close to the users to preserve compute resources and improve performances of the API. 32 | 33 | 34 | 35 | ### Example 36 | TBD 37 | 38 | ### Validation principle 39 | 40 | true of false -------------------------------------------------------------------------------- /chapters/DE06_en.md: -------------------------------------------------------------------------------- 1 | ## Use Event Driven Architecture to avoid polling madness. 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | DE06 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Design | Network / Storage | API Producer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / storage | 24 | 25 | ### Description 26 | 27 | When configuring a cache, it often happens that the data refresh policy (TTL) is not synchronized with the data life cycle. 28 | 29 | In this case, the cache is not fully efficient because the data is expired too early or too late. 30 | 31 | It is necessary to provide an expiration policy adapted to the data refresh cycle and to allow partial expiration of the cached data in order to be as efficient as possible on all the processed data. To optimize the cache as much as possible, it is also possible to build an architecture where the source of the data notifies, via an event, the cache of the expiration of a specific data. 32 | 33 | 34 | 35 | 36 | ### Example 37 | TBD 38 | 39 | ### Validation principle 40 | 41 | true of false -------------------------------------------------------------------------------- /chapters/DE07_en.md: -------------------------------------------------------------------------------- 1 | ## Construct your API with customer centricity principles. 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | DE07 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Design | Network/Compute | API Producer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / compute | 24 | 25 | ### Description 26 | 27 | Sometimes the data returned by an API is structured in such a way that, in order to have all the data the user needs, it is necessary to make several requests to the same API. 28 | 29 | This has the consequence of increasing the consumption of bandwidth and computing resources, for the API that has to process several requests, and of bandwidth. 30 | 31 | Therefore, it is important to provide a consistent data structure regarding the use of the API. This client-centric best practice prevents the consumer from having to perform multiple queries to retrieve all the information they need. 32 | 33 | 34 | 35 | ### Example 36 | TBD 37 | 38 | ### Validation principle 39 | 40 | true of false -------------------------------------------------------------------------------- /chapters/DE08_en.md: -------------------------------------------------------------------------------- 1 | ## Implement filters to limit which fields are returned by the API (send just the data the consumer need). 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | DE08 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Design | Network/Compute/Storage | API Producer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / compute / storage | 24 | 25 | ### Description 26 | 27 | It often happens that the implementation of filters in the APIs allowing to return only the necessary data to the consumers are forgotten or not efficient. 28 | 29 | This forces API consumers to make generic requests that retrieve unnecessary amounts of information, resulting in overconsumption of bandwidth and storage. 30 | 31 | It is recommended to design and implement filters that allow the user to limit the amount of data returned to optimize network and storage consumption. 32 | 33 | 34 | 35 | ### Example 36 | For instance, we want to know the postal addresses of stores in a city. Originally, the service does not provide filtering on the search endpoint, so each time we want to know the addresses we fetch _all_ addresses and _then_ filter the ones in the city. The API can potentially transfer a huge amount of useless data. 37 | 38 | With figures: 39 | - the service has 1000 addresses, representing 22kB of data for each query 40 | - we want to filter for a city that only has 30 stores, making 1.3kB of data 41 | - this represents 20kB useless data 42 | - for an endpoint requested 500k times per day, this is 10GB of useless data transfered daily. 43 | 44 | Here is a simple setup: 45 | ```java 46 | @GetMapping 47 | public ResponseEntity> getAddresses(@RequestParam(defaultValue = "") String filter) { 48 | return ResponseEntity.ok(addresses 49 | .stream() 50 | .filter(a -> a.contains(filter)); 51 | } 52 | ``` 53 | This can be used by a simple request: `GET /addresses?filter=Marseille` 54 | 55 | ### Validation principle 56 | 57 | true of false 58 | -------------------------------------------------------------------------------- /chapters/DE09_en.md: -------------------------------------------------------------------------------- 1 | ## Leverage OData or GraphQL for your databases APIs 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | DE09 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Design | Network/Compute/Storage | API Producer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / compute / storage | 24 | 25 | ### Description 26 | 27 | It is quite common to see API backends built to allow database integration. In some cases, these systems are completely redeveloped with data schemas that are not adapted to the usage. 28 | 29 | This forces users to perform several queries, often complex, to retrieve all the data they need. 30 | 31 | To build an interface to a database, it is recommended to rely on OData or GraphQL technologies that allow consumers to perform complex queries. 32 | 33 | 34 | ### Example 35 | TBD 36 | 37 | ### Validation principle 38 | 39 | true of false -------------------------------------------------------------------------------- /chapters/DE10_en.md: -------------------------------------------------------------------------------- 1 | ## Redundant data information in the same API 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | DE10 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Design | Network/Compute/Storage | API Producer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / compute / storage | 24 | 25 | ### Description 26 | 27 | To reduce the risk of misinterpretation caused by data duplication and streamline the communication process. 28 | 29 | Each piece of data should be essential and distinct to the operation at hand. 30 | 31 | Duplicate data can lead to confusion and misinterpretation, as consumers of the API may not be able to determine which data points are relevant or current. 32 | 33 | Ensuring data uniqueness within API responses prevents such misunderstandings and simplifies data parsing and handling. 34 | 35 | By enforcing this rule, we ensure that each API response is concise and that the data provided is a clear and accurate representation of the requested information. Redundant data inflates the payload, increases processing time. 36 | 37 | 38 | 39 | 40 | ### Example 41 | TBD 42 | 43 | ### Validation principle 44 | 45 | true of false 46 | -------------------------------------------------------------------------------- /chapters/DE11_en.md: -------------------------------------------------------------------------------- 1 | ## Availability of pagination 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | DE11 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Design | Network/Compute/Storage | API Producer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / compute / storage | 24 | 25 | ### Description 26 | 27 | Implement pagination to limit which data are returned by the API (send just the data the consumer need) using for exemple "next", "skip", "top", … 28 | 29 | Check payload log to validate if pagination keywords are used 30 | 31 | 32 | ### Example 33 | TBD 34 | 35 | ### Validation principle 36 | 37 | true of false -------------------------------------------------------------------------------- /chapters/LO01_en.md: -------------------------------------------------------------------------------- 1 | ## Collect only required data and use the right retention time according to the business requirements. 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | LO01 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Logs | Network/Storage | API Producer/API Consumer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / storage | 24 | 25 | ### Description 26 | 27 | It is quite common for applications to store a large amount of useless information without time limit. 28 | This results in an excessive consumption of storage services for data that will not be used or no longer used. 29 | 30 | It is necessary to clean up the data in order to keep only the data that is useful and to define a coherent retention policy in order to delete them once their validity or exploitation period has passed. 31 | 32 | 33 | 34 | ### Example 35 | TBD 36 | 37 | ### Validation principle 38 | 39 | true of false -------------------------------------------------------------------------------- /chapters/US01_en.md: -------------------------------------------------------------------------------- 1 | ## Use query parameters for GET Methods 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | US01 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Usage | Network/Compute | API Consumer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / compute | 24 | 25 | ### Description 26 | 27 | Optimize queries to limit the information returned to what is strictly necessary. 28 | 29 | It is often observed that requests made on APIs are not precise enough, which returns a volume of information greater than necessary. 30 | 31 | This results in increased bandwidth consumption during exchanges. 32 | 33 | The best practice is to create precise requests that return, as much as possible, the strictly necessary information, thus avoiding the transfer of useless information. 34 | 35 | This rule is linked to DE08 : “Implement filters to limit which fields are returned by the API ” 36 | 37 | 38 | 39 | ### Example 40 | TBD 41 | 42 | ### Validation principle 43 | 44 | true of false -------------------------------------------------------------------------------- /chapters/US02_en.md: -------------------------------------------------------------------------------- 1 | ## Decommission end of life or unused APIs. 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | US02 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Usage | Compute | API Producer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | | compute | 24 | 25 | ### Description 26 | 27 | It often happens that the APIs of an information system are rarely or no longer used but are not decommissioned. 28 | 29 | This leads to the consumption of computing resources for useless or obsolete components. 30 | It is important that the decommissioning phase is also treated as part of the application life cycle in order to free up allocated resources. In the case of a rarely used API, a root cause analysis should be performed prior to decommissioning to understand why it is not used more often. 31 | 32 | 33 | 34 | ### Example 35 | TBD 36 | 37 | ### Validation principle 38 | 39 | true of false -------------------------------------------------------------------------------- /chapters/US03_en.md: -------------------------------------------------------------------------------- 1 | ## Number of API <=2 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | US03 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Usage | Compute / Storage | API Producer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | | compute / storage | 24 | 25 | ### Description 26 | 27 | Have a good lifecycle management of API by reducing the number of API version on production 28 | The value of 2 release can be challenge depending of your context. 29 | Less version permit to have less technical debt. 30 | 31 | 32 | 33 | ### Example 34 | TBD 35 | 36 | ### Validation principle 37 | 38 | true of false -------------------------------------------------------------------------------- /chapters/US04_en.md: -------------------------------------------------------------------------------- 1 | ## Usage of pagination of results available 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | US04 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Usage | Network/Compute | API Consumer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / compute / storage | 24 | 25 | ### Description 26 | 27 | Some request can return a huge volume of data. We can optimize the response by using pagination. 28 | 29 | A control can be used to check some keywords like next, skip, top, etc … 30 | 31 | This rule is linked to DE11 : “Availability of pagination” 32 | 33 | 34 | 35 | 36 | ### Example 37 | TBD 38 | 39 | ### Validation principle 40 | 41 | true of false -------------------------------------------------------------------------------- /chapters/US05_en.md: -------------------------------------------------------------------------------- 1 | ## Choose the correct API based on use case to avoid requests on multiple systems or large number of requests. Refer to the data catalog to validate the data source 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | US05 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Usage | Network/Compute | API Consumer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / compute | 24 | 25 | ### Description 26 | 27 | We often notice that applications, in order to refresh their data, make very frequent requests to APIs. 28 | This causes an important workload and we increase the computing resources to absorb this load in order not to penalize the other users. 29 | 30 | The best practice is to use an event-driven architecture in order to receive a notification when a piece of information is modified to avoid making regular useless requests. But the data contained in the event must be precise to be sure to avoid a system making a request to retrieve an unused data. 31 | 32 | 33 | 34 | ### Example 35 | TBD 36 | 37 | ### Validation principle 38 | 39 | true of false -------------------------------------------------------------------------------- /chapters/US06_en.md: -------------------------------------------------------------------------------- 1 | ## Well designed and documented API to increase reuse rate 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | US06 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Usage | Network/Compute | API Consumer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / compute | 24 | 25 | ### Description 26 | 27 | Deploy a well designed and documented API to increase the reuse rate and improve time to market. 28 | 29 | Based on documentation provided in the API Portal. 30 | 31 | The more accurate the documentation, the easier it will be for consumers to understand and use the API. 32 | 33 | This indicator is a percentage rate. 34 | 35 | 36 | ### Example 37 | TBD 38 | 39 | ### Validation principle 40 | 41 | rate 42 | 43 | This is a sample rate calculation = (Number of consumers *50) - 50, if you have more than 100%, it will be a bonus. -------------------------------------------------------------------------------- /chapters/US07_en.md: -------------------------------------------------------------------------------- 1 | ## Error Rate 2 | 3 | ### Identifiers 4 | 5 | | API Green Score | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | US06 | 1 | | | 8 | 9 | ### Categories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Usage | Network/Compute | API Producer/API Consumer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Difficulty | Ecological Impact Level | 18 | |:-------------------:|:-------------------------:|:---------------------:| 19 | | tbd | tbd | tbd | 20 | 21 | |Saving Resources | 22 | |:----------------------------------------------------------:| 23 | |network / compute | 24 | 25 | ### Description 26 | 27 | Decrease the error rate (results different from 2xx) to avoid over processing. 28 | 29 | Depending of your context, you can focus on 4xx or 5xx errors, or both. 30 | 31 | One of objectives of this rule is to improve the quality of requests (fill all required fields, or better control of contract,etc… ) and improved the response if we have to many errors due to tech 32 | 33 | 34 | ### Example 35 | TBD 36 | 37 | ### Validation principle 38 | 39 | rate 40 | 41 | This is a sample rate calculation = (Number of consumers *50) - 50, if you have more than 100%, it will be a bonus. -------------------------------------------------------------------------------- /resources/APIGreenScore.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/API-Green-Score/APIGreenScore/6f96ef9bdf95a090a192badc2f68d57f82e92132/resources/APIGreenScore.ico -------------------------------------------------------------------------------- /resources/APIGreenScore_logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/API-Green-Score/APIGreenScore/6f96ef9bdf95a090a192badc2f68d57f82e92132/resources/APIGreenScore_logo.png -------------------------------------------------------------------------------- /resources/YYxx_en.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | 3 | ### Identifiers 4 | 5 | | GreenIT | V1 | V2 | V3 | 6 | |:-------:|:----:|:----:|:----:| 7 | | | | | | 8 | 9 | ### Catégories 10 | 11 | | Lifecycle | Resources | Responsible | 12 | |:---------:|:----:|:----:| 13 | | Architecture | Network/Compute | API Producer/API Consumer | 14 | 15 | ### Indications 16 | 17 | | Priority Level | Implementation Level | Impact écologique | 18 | |-------------------|:-------------------------:|:---------------------:| 19 | | | | | 20 | 21 | ### Description 22 | 23 | ... 24 | 25 | ### Example 26 | 27 | (optional) ... 28 | 29 | ### Alternative solution 30 | 31 | (optional) ... 32 | 33 | ### Validation principle 34 | 35 | true of false or TBD -------------------------------------------------------------------------------- /resources/apigreenscore_logo_byCAT.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/API-Green-Score/APIGreenScore/6f96ef9bdf95a090a192badc2f68d57f82e92132/resources/apigreenscore_logo_byCAT.png --------------------------------------------------------------------------------