2 ms·
The convention that Django REST Framework (which is an add-on for Django, not part of the core) uses is to add a 'url' attribute to each resource to represent t
by po 14y ago
The convention that Django REST Framework (which is an add-on for Django, not part of the core) uses is to add a 'url' attribute to each resource to represent the cannonical id.
Even better, when you hit the API with a browser, you can click around and explore the links easily:
http://restframework.herokuapp.com/users/ http://restframework.herokuapp.com/users/
The docs talk about it a bit here:
http://django-rest-framework.org/tutorial/5-relationships-and-hyperlinked-apis.html http://django-rest-framework.org/tutorial/5-relationships-an...
- alecperkins 14y agoI like to take this one step further and return referenced objects with both their ID and their URL as actual objects instead of strings. This is incredibly helpful for working with the API in something like Backbone.js, because then there's no need for logic in determining if it is getting a list of IDs as strings or full objects. It's doubly helpful if the references are to objects of different types. The client simply loads the objects as given, and can do a sync if it's missing attributes it expects. (Of course, sending the full data in one request is usually preferable.) Also, the `url` property on the model just returns the `url` attribute instead of needing to duplicate the URL construction pattern. So, … { 'id': 123, 'url': '/resource/123' }, … instead of … '/resource/123', '/resource/124', … or worse … 123, 124, … Also, Django REST Framework is easily my favorite REST API tool for Django. It's very straightforward to use just as much or just as little of it as necessary. In fact, it's powering the main views of the upcoming second draft of http://marquee.by http://marquee.by (the entire site is effectively a browsable API).