Feature: affecting_items field to stats #1309 *Rebased to recent master branch* #1310
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What I Changed
Added a new affecting_items field to the StatDetailSerializer that returns items (vitamins and battle items) that affect each stat. This enhancement brings the stat endpoint in line with the existing affecting_moves and affecting_natures fields, providing a complete picture of all factors that can modify a Pokémon's stats.
Files Modified:
Highlights
How to Use
API Endpoint: GET /api/v2/stat/{id}/
Example Request:
curl https://pokeapi.co/api/v2/stat/2/
Example Response (for Attack stat):
{
"id": 2,
"name": "attack",
"affecting_items": [
{
"name": "protein",
"url": "https://pokeapi.co/api/v2/item/46/"
},
{
"name": "x-attack",
"url": "https://pokeapi.co/api/v2/item/47/"
}
],
"affecting_moves": { ... },
"affecting_natures": { ... },
...
}
Significance
This change completes the stat detail endpoint by providing comprehensive information about all game mechanics that affect stats. Previously, the API only exposed moves and natures that affect stats, but items are equally important in the Pokémon games for:
This makes the PokéAPI more useful for:
The implementation maintains backward compatibility (purely additive) and follows the existing API design patterns, making it intuitive for current API consumers to adopt.