Proposal: Deprecate and remove Tastypie in favor of a unified DRF-based API #13836
Description
GeoNode currently exposes REST APIs through three overlapping layers:
- Django REST Framework (DRF)
- Dynamic REST (as an extension on top of DRF)
- Tastypie (legacy)
While this is understandable from a historical perspective, today it introduces technical debt, duplicated concepts, and unnecessary cognitive overhead for both maintainers and integrators.
This issue proposes a planned deprecation and eventual removal of Tastypie, migrating remaining endpoints to DRF (optionally using Dynamic REST where appropriate).
Current situation
At present:
- DRF is the primary framework used for new APIs and most actively maintained endpoints.
- Dynamic REST is used to optimize DRF responses for complex frontend use cases (filtering, includes, sparse fields).
- Tastypie is still used by several endpoints, mainly for:
- Legacy API compatibility
- Older integrations and clients
- Historical GeoNode 2.x design decisions
This results in:
- Two different REST frameworks solving the same problem
- Different serialization styles, filtering mechanisms, and auth behaviors
- Higher maintenance cost and steeper learning curve for contributors
Known areas still using Tastypie
While not exhaustive, Tastypie is still involved in areas such as:
- Some legacy resource endpoints under
/api/ - Parts of resource listing and metadata access
- Older clients and scripts relying on Tastypie response formats
- Compatibility layers preserved for backward support
(These could be catalogued explicitly as part of the deprecation process.)
Why this matters
1. Technical debt reduction
- Maintaining two REST frameworks increases complexity without functional benefit.
- Tastypie is effectively in maintenance mode and no longer represents modern Django best practices.
2. Consistency
- DRF is already the de facto standard in GeoNode.
- A single API framework means consistent auth, permissions, serializers, pagination, filtering, and documentation.
3. Developer experience
- New contributors must currently understand DRF and Tastypie.
- Users extending GeoNode APIs often get confused about which framework to use.
4. Ecosystem alignment
- DRF integrates naturally with:
- OpenAPI / Swagger
- Modern frontend clients
- OAuth / OIDC (Keycloak, etc.)
- Tastypie does not offer the same level of tooling or community momentum.
5. Future evolution
- Modern API patterns (hypermedia control, fine-grained permissions, schema generation, async views) are DRF-first.
- Keeping Tastypie blocks or delays adoption of newer Django features.
Proposed path forward
-
Declare Tastypie as deprecated
- Clearly mark it as legacy in documentation.
- Discourage new usage.
-
Inventory existing Tastypie endpoints
- Identify which ones are still required.
- Assess usage and backward-compatibility constraints.
-
Reimplement remaining endpoints in DRF
- Match existing response contracts where feasible.
- Optionally provide compatibility serializers during transition.
-
Provide a deprecation window
- Keep Tastypie endpoints read-only or frozen.
- Emit warnings or documentation notices.
-
Remove Tastypie dependency
- Once migration is complete and compatibility window closes.
Expected benefits
- Cleaner architecture
- Lower maintenance burden
- Clear guidance for contributors and integrators
- Stronger alignment with modern Django and API standards
- A single, extensible REST surface for GeoNode
Closing note
This proposal does not suggest a breaking change without planning.
Rather, it advocates for a controlled, explicit modernization path that reflects how GeoNode is already evolving internally.
Contributors are welcome to help with:
- Endpoint inventory
- Migration strategy
- Compatibility layer design