GraphQL attribute types inconsistent with REST api #11699

New Issue

adam · 2025-12-29T21:48:45+01:00

adam commented

2025-12-29 21:48:45 +01:00

Originally created by @AdilsonTorres on GitHub (Oct 6, 2025).

NetBox Edition

NetBox Community

NetBox Version

v4.x

Python Version

3.10

Steps to Reproduce

Request a graphql model like:
{
site_list{
id,
name,
region {
id
name
}
}
}

Expected Behavior

A list with correct types, like the REST api:
{
"data": {
"site_list": [
{
"id": 24,
"name": "Butler Communications",
"region": {
"id": 40,
"name": "North Carolina"
}
},
...

Observed Behavior

A list with wrong types in the int values as string, I found a closed issue but with no conclusion (#11472):

{
"data": {
"site_list": [
{
"id": "24",
"name": "Butler Communications",
"region": {
"id": "40",
"name": "North Carolina"
}
},
...

Originally created by @AdilsonTorres on GitHub (Oct 6, 2025). ### NetBox Edition NetBox Community ### NetBox Version v4.x ### Python Version 3.10 ### Steps to Reproduce 1. Request a graphql model like: { site_list{ id, name, region { id name } } } ### Expected Behavior A list with correct types, like the REST api: { "data": { "site_list": [ { "id": 24, "name": "Butler Communications", "region": { "id": 40, "name": "North Carolina" } }, ... ### Observed Behavior A list with wrong types in the int values as string, I found a closed issue but with no conclusion (#11472): { "data": { "site_list": [ { "id": "24", "name": "Butler Communications", "region": { "id": "40", "name": "North Carolina" } }, ...

adam added the type: bug label 2025-12-29 21:48:45 +01:00

adam closed this issue

2025-12-29 21:48:45 +01:00

adam commented

2025-12-29 21:48:46 +01:00

@jnovinger commented on GitHub (Oct 9, 2025):

Thank you for the report, @AdilsonTorres . I believe this behavior is actually working as designed and is part of the GraphQL specification.

The GraphQL ID scalar type is defined by the GraphQL spec to be "serialized in the same way as a String" even though it represents a unique identifier.

From the GraphQL specification:

"The ID scalar type represents a unique identifier, often used to refetch an object or as key for a cache. The ID type appears in a JSON response as a String; however, it is not intended to be human‐readable."

Strawberry GraphQL (which NetBox uses) explicitly documents that ID is "a specialised String for representing unique object identifiers." This was previously discussed in detail in #11472, where we confirmed that NetBox 4.x's Strawberry GraphQL implementation correctly follows the GraphQL specification.

While this does differ from the REST API's behavior, it appears to be the correct and expected behavior for GraphQL APIs. Clients should treat ID values as opaque identifiers regardless of their serialization format.

@jnovinger commented on GitHub (Oct 9, 2025): Thank you for the report, @AdilsonTorres . I believe this behavior is actually working as designed and is part of the GraphQL specification. The GraphQL `ID` scalar type is [defined by the GraphQL spec](https://graphql.org/learn/schema/#scalar-types) to be "serialized in the same way as a String" even though it represents a unique identifier. From the GraphQL specification: > "The ID scalar type represents a unique identifier, often used to refetch an object or as key for a cache. The ID type appears in a JSON response as a String; however, it is not intended to be human‐readable." Strawberry GraphQL (which NetBox uses) [explicitly documents](https://strawberry.rocks/docs/types/scalars#scalars) that ID is "a specialised `String` for representing unique object identifiers." This was previously discussed in detail in #11472, where we confirmed that NetBox 4.x's Strawberry GraphQL implementation correctly follows the GraphQL specification. While this does differ from the REST API's behavior, it appears to be the correct and expected behavior for GraphQL APIs. Clients should treat ID values as opaque identifiers regardless of their serialization format.

adam commented

2025-12-29 21:48:46 +01:00

@jeremystretch commented on GitHub (Oct 9, 2025):

Please also bear in mind that the REST and GraphQL APIs are completely different bests. Consistency between them has never been a design goal, as each serves different purposes.

@jeremystretch commented on GitHub (Oct 9, 2025): Please also bear in mind that the REST and GraphQL APIs are completely different bests. Consistency between them has never been a design goal, as each serves different purposes.

adam commented

2025-12-29 21:48:47 +01:00

@AdilsonTorres commented on GitHub (Oct 9, 2025):

Thanks for the answers. Trying to keep them similar indeed is not a good design.

@AdilsonTorres commented on GitHub (Oct 9, 2025): Thanks for the answers. Trying to keep them similar indeed is not a good design.

Sign in to join this conversation.

Branches Tags

main

21102-fix-graphiql-explorer

update-changelog-comments-docs

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#11699