4 ms·
It's not a limitation of django - subclasses of HttpResponse exist for certain error codes, and their content can be set in the normal manner. https://docs.dja
by motter 15y ago
It's not a limitation of django - subclasses of HttpResponse exist for certain error codes, and their content can be set in the normal manner.
https://docs.djangoproject.com/en/dev/ref/request-response/#httpresponse-subclasses https://docs.djangoproject.com/en/dev/ref/request-response/#...
Agreed - 'depth' makes more sense as a GET parameter, since it's a resource in its own right.
- sanderjd 15y agoIt definitely makes sense to have it in the query string, and I think people are already doing it that way, but the author makes a good point - it isn't a resource in its own right, it's merely a different representation. But in my experience, requiring Accept manipulation outside of .json versus .xml makes your service less usable by clients, which often don't expose anything besides the url.
- masklinn 15y agoI think both interpretations can be defended. Though if you're playing with the Accept: header it's important to correctly set Vary: as well. > But in my experience, requiring Accept manipulation outside of .json versus .xml makes your service less usable by clients, which often don't expose anything besides the url. Browsers have that limitation (and numerous others), but if a programmatic HTTP library does not expose this, you need to throw it out. The Accept header is not part of the "immutable" headers of XHR either.
- justincormack 15y agoit is not a different representation, it is a different resource. Imagune if you PUT it, it has a different meaning with different depth.