starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Execute Export template from API #2994

New Issue
Closed
opened 2025-12-29 18:24:29 +01:00 by adam · 7 comments
adam commented 2025-12-29 18:24:29 +01:00
Owner
Copy Link

Originally created by @itmicus on GitHub (Nov 3, 2019).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.7.3
  • NetBox version: 2.6.6

Proposed Functionality

Execute Export templates from Netbox API

Use Case

Now, I can execute Export templates from UI, but I need get export template from API by my script.
Netbox using authentification for access to UI

Database Changes

None

External Dependencies

None.

Originally created by @itmicus on GitHub (Nov 3, 2019). Originally assigned to: @jeremystretch on GitHub. ### Environment * Python version: 3.7.3 * NetBox version: 2.6.6 ### Proposed Functionality Execute Export templates from Netbox API ### Use Case Now, I can execute Export templates from UI, but I need get export template from API by my script. Netbox using authentification for access to UI ### Database Changes None ### External Dependencies None.
adam added the status: acceptedtype: feature labels 2025-12-29 18:24:29 +01:00
adam closed this issue 2025-12-29 18:24:29 +01:00
adam commented 2025-12-29 18:24:30 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 4, 2019):

I don't think that returning rendered export templates via the REST API is feasible given that all API responses must be structured JSON, and export templates by nature produce arbitrary output. We could encapsulate their output within a JSON field, but that 1) introduces the risk that we won't be able to properly serialize rendered content, and 2) greatly reduces the utility of the feature.

It sounds like what you really need is just a mechanism for reliably authenticating to the current mechanism for rendering export templates, is that correct?

@jeremystretch commented on GitHub (Nov 4, 2019): I don't think that returning rendered export templates via the REST API is feasible given that all API responses must be structured JSON, and export templates by nature produce arbitrary output. We _could_ encapsulate their output within a JSON field, but that 1) introduces the risk that we won't be able to properly serialize rendered content, and 2) greatly reduces the utility of the feature. It sounds like what you really need is just a mechanism for reliably authenticating to the current mechanism for rendering export templates, is that correct?
adam commented 2025-12-29 18:24:30 +01:00
Author
Owner
Copy Link

@sdktr commented on GitHub (Nov 5, 2019):

Maybe these exports should be made async based on the RQ worker? API could then be used to schedule the export, publishing a link to a file that contains the output once ready.

@sdktr commented on GitHub (Nov 5, 2019): Maybe these exports should be made async based on the RQ worker? API could then be used to schedule the export, publishing a link to a file that contains the output once ready.
adam commented 2025-12-29 18:24:31 +01:00
Author
Owner
Copy Link

@itmicus commented on GitHub (Nov 5, 2019):

I don't think that returning rendered export templates via the REST API is feasible given that all API responses must be structured JSON, and export templates by nature produce arbitrary output. We could encapsulate their output within a JSON field, but that 1) introduces the risk that we won't be able to properly serialize rendered content, and 2) greatly reduces the utility of the feature.

sure, I think so, it is not good idea, responcing rendered tempalte in JSON field.

For example,
GET /api/export-template/{ID}/
Content-Type: {MIME type from export-template}

It sounds like what you really need is just a mechanism for reliably authenticating to the current mechanism for rendering export templates, is that correct?

It is correct, but I think using the API is more logical

@itmicus commented on GitHub (Nov 5, 2019): > I don't think that returning rendered export templates via the REST API is feasible given that all API responses must be structured JSON, and export templates by nature produce arbitrary output. We _could_ encapsulate their output within a JSON field, but that 1) introduces the risk that we won't be able to properly serialize rendered content, and 2) greatly reduces the utility of the feature. sure, I think so, it is not good idea, responcing rendered tempalte in JSON field. For example, GET /api/export-template/{ID}/ Content-Type: {MIME type from export-template} > It sounds like what you really need is just a mechanism for reliably authenticating to the current mechanism for rendering export templates, is that correct? It is correct, but I think using the API is more logical
adam commented 2025-12-29 18:24:31 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 5, 2019):

Maybe these exports should be made async based on the RQ worker? API could then be used to schedule the export, publishing a link to a file that contains the output once ready.

There is no need for that. Export templates are rendered on-demand, in the same manner as a list of objects fetched via the REST API. The only additional overhead is whatever rendering logic is imposed in a template.

@jeremystretch commented on GitHub (Nov 5, 2019): > Maybe these exports should be made async based on the RQ worker? API could then be used to schedule the export, publishing a link to a file that contains the output once ready. There is no need for that. Export templates are rendered on-demand, in the same manner as a list of objects fetched via the REST API. The only additional overhead is whatever rendering logic is imposed in a template.
adam commented 2025-12-29 18:24:31 +01:00
Author
Owner
Copy Link

@darcynz commented on GitHub (Feb 11, 2020):

We've approached this feature request as we build our Automation Pipeline using Netbox as the source of truth for configuration.

Whilst we can get the data via API calls to the objects, using export templates would help present the data organised for models that we want to deploy. This would need to be via API to be be part of our CICD pipeline.

Could one option be to create an API first export template that would conform for serialization purposes?

@darcynz commented on GitHub (Feb 11, 2020): We've approached this feature request as we build our Automation Pipeline using Netbox as the source of truth for configuration. Whilst we can get the data via API calls to the objects, using export templates would help present the data organised for models that we want to deploy. This would need to be via API to be be part of our CICD pipeline. Could one option be to create an API first export template that would conform for serialization purposes?
adam commented 2025-12-29 18:24:31 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 8, 2020):

I've done some digging into this, and while I have gotten it to work, I'm concerned about the performance implications. Using a custom renderer, we can't use the response data directly because it's already been serialized, and an ExportTemplate expects to work with a raw queryset (or at least a list of instances). While we can access the original queryset from the view and perform the same filtering, this is done only after the serialized response is generated, so we incur the overhead of both serialization and template rendering for a single request.

Ideally, we want to be able to bypass model serialization entirely. I'm not sure that's feasible given that it's obviously a central component of the API framework. We may have to come up with an alternative approach.

@jeremystretch commented on GitHub (Apr 8, 2020): I've done some digging into this, and while I have gotten it to work, I'm concerned about the performance implications. Using a [custom renderer](https://www.django-rest-framework.org/api-guide/renderers/#custom-renderers), we can't use the response data directly because it's already been serialized, and an ExportTemplate expects to work with a raw queryset (or at least a list of instances). While we can access the original queryset from the view and perform the same filtering, this is done only _after_ the serialized response is generated, so we incur the overhead of both serialization _and_ template rendering for a single request. Ideally, we want to be able to bypass model serialization entirely. I'm not sure that's feasible given that it's obviously a central component of the API framework. We may have to come up with an alternative approach.
adam commented 2025-12-29 18:24:32 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 10, 2021):

Going to take another stab at this for v2.12

@jeremystretch commented on GitHub (May 10, 2021): Going to take another stab at this for v2.12
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#2994
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?