Forgive this newbie (and possibly subjective - I don't know) question.
I want to add a REST API to my site. For example, I have a URL that is /post/ that shows all posts, and I'd like to give users a way to get all posts back in JSON.
Is is better to:
define a new API URL structure (e.g. /api/rest/post/ to return all posts in JSON)
use the existing URL structure, and allow users simply to append /json/ on the end of each URL to get JSON objects back? (e.g. /post/json/ to return all posts in JSON)
If the latter, then is there a standard way to implement it, in terms of views? Should I simply add an optional json parameter to all my views?
Thank you for your advice.
Take a look at Piston, which is a Django plugin to handle REST APIs.
Listen to the previous commenter's advise. But in particular that's probably better to use new API URL structure (/api/rest/post/ as you've said). Separating totally different kinds of functionality is always good for your project. In other words, you can place your API documentation at /api/docs/, and it will look natural. If you use same URL structure, it will be not so obvious where to place your docs.
The answer is of course also subjective.
Related
How to create something like this:
If user is in:
http://127.0.0.1:8000/about/ then in my base.html I have:
You are here: <li>Home</li>
Etc.
Is there a simple way?
This can get tricky, depending on what you mean by "breadcrumbs".
Django's URL routing system has no inherent hierarchy since any URL can map to any view.
So the "hierarchy" has to be completely specified by you.
…and passed by you to the template in either your view, or in a context processor.
You'll want to assign both a URL AND a name for the URL (so you know /about/ is "Home").
There are a bajillion ways to do this, and it all sort of depends on how flexible you want it, how complicated your URL patterns get, whether you want to support nesting, etc.
Normally, I just use Django Breadcrumbs. This project handles all of the weirdness of breadcrumbs, has a very easy to use API, and handles even weird cases.
While a full code sample would probably be helpful, it's a long and thorny problem, so you're better off reading the documentation for django-breadcrumbs, and then returning here with questions.
Apologies if this has been discussed before, have searched and searched but didn't find anything useful :)
But here goes.
We're currently in the process of rewriting a portion of our webapp. Our app is rather old and therefore suffers from some rather cowboy'ish approaches to programming, conventions and urls.
What we're looking for is a simple clean way to design our views and urls so that we can maintain both easier in the future.
The problem is; as of now our urls.py file for the main site is one big mess. a lot of urls that point to a unique view that only does one thin.
Ex. list_books/, edit_book/ etc.
when it comes to specific formats etc. we have something like list_books_json/
(these aren't the actual urls though, but just used to prove a point since the real urls are much worse)
What we want to do now is clean it up a bit. And we we're wondering what the best way to get around it would be??
What we have thought of so far(after reading a lot of things on the subject):
We've thought of designing our urls after the following pattern:
domain/object/action/
so the urls for the apps "staff" site for changing books in the app would be:
staff/books - to view all books (GET)
staff/books/ID - to view one books (GET)
staff/books/new - to create a new book (POST)
staff/books/ID/edit - to edit specific books (POST)
staff/books/ID/delete - to delete specific books (POST)
The thought was then to have only 1 view, views.staff_books() to handle all these actions when dealing with books through the "staff" part of the site.
so that staff_books() checks for ID or a certain "action" (edit, new, delete etc.)
The result would be fewer, but a lot larger views that have to handle all aspects of staff/books. Right now we have a ton of small views that handle only one thing.
Does this makes sense, can you see potential problems? How do you guys go about it??
One place where I think we're lost is in regards to formats.
Where would you put ex. the request for returning the response in json?
we're wondering "staff/books.json" or "staff/books/ID.json" etc. and then keeping all the json logic in the same "staff_books()" view.
So thats it basically. I'm sorry the question is a little "fluffy"... We basically need some examples or good design advice as to how to structure urls and views.
Kind Regards
pete
As an extension (and solution) to your problem I would suggest to use the strategy pattern. Since you already have a structure and the only thing that differs is "how" it is supposed to be carried out, this pattern fits your problem perfectly. What I mean by that is the following:
Create a view which is your entry point to your application with functions named as your url-based functionality (edit, new, delete etc.). I.e where your url.py determines where to go from there.
Create classes which do your stuff based on your domains etc. Lets call them Book, Calendar etc for now.
Implement functionality of those classes, like edit, new, delete etc.
in your view then, determine what class to instantiate and call the corresponding function, e.g in View.edit() call domain.edit()
I think that should do it ^^
Hope it helps :D
for seo related reason in my project i have to trap certain search parameters within the url for the "beautiful url" thing.
The advanced search is composed by 7 parameters, 3 of which are location-related and are the ones interesting our seo consultant.
So, now i'm a bit confused. It's been a while since i started using django professionally, but never had to face an issue like this. Basically, the final url structure must be something like this:
/Italy/Lombardy/Milan/?price=100&miles=10&last_posted=2
and my urls.py is
'/(?P<country>\w+)/(?P<zone>\w+)/(?P<city>\w+)/$', SearchView.as_view()
now, what i'm not sure about is how should i specify my request in the form method to be able to use that exact url schema? POST or GET? And how can i compose the url for the "action" attribute dynamically while the user types? Is this even the correct solution? I'm really confused about it, any help would be really appreciated! Thanks!
you will have to change the action field of the form using script, yes. and set the method to GET, and include in the form only the fields appearing in the query string.
I want to combine pagination with filtering. Since I have a lot of filters I do not want to send them per GET request, since the URLs get really ugly.
Since django pagination uses GET request to pass the page parameters, I do not know how I can combine these two approaches.
Any idea?
Great add-on would be: How can I combine this approach with table sort? :-)
Edit:
Actually it should work like the pagination of stackoverflow - user questions. If a user clicks on a page number one is shown the correct page, without showing the get parameters in the url.
This is the url called.
https://stackoverflow.com/api/userquestions.html?page=2&pagesize=10&userId=237690&sort=Recent
But the url shown in the browser is neat and short.
Seems to be ajax. Anybody an idea how to implement this? :)
If the URL is not shown in the browser`s address bar, I do not care about whether it is beautiful or not.
Edit: The solution:
Make an ajax update with all filter parameters passed to the view. This should help you get started with implementing ajax for your site: link
Thus the GET parameters never show up in the address bar.
have you checked the paginate application for django?
it may help you a lot, use it all the time :D
http://code.google.com/p/django-pagination/
Have you considered django-tables2? It gives you django-admin style tables without you having to write the logic yourself.
maybe you can use the urs, something like:
http://oursite.com/something/filter1/filter2/3/
the doc -> http://docs.djangoproject.com/en/1.1/topics/http/urls/
I figured out two solutions:
Instead of using just hyperlinks use it inside a POST form, i dont have any example now but i remember have used that for REST functions in Ruby on rails
Save the query info in a session.
Hope this help.
I'm developing a blog application using Django. Currently, the URL /blog/ displays the front page of the blog (the first five posts). Visitors can then browse or "page through" the blog entries. This portion is mapped to /blog/browse/{page}/, where page, of course, is an integer that specifies which "page" of blog entries should be displayed.
It's occurred to me, though, that perhaps the "page number" should be an attribute of the querystring instead (e.g., /blog/browse/?page=2), since the content of the browse pages is not static (i.e., as soon as I add another post, /blog/browse/2/ will have different contents than it had before the post was added). This seems to be the way sites like Stack Overflow and Reddit do things. For example, when paging through questions on Stack Overflow, a "page" attribute is used; likewise, Reddit uses a "count" attribute.
Extending this thinking, I realize that I use the same template to render the contents of both /blog/ and /blog/browse/, so it might even make sense to just use a URL like /blog/?page=2 to page through the contents of the blog.
Any suggestions? Is there a "standard" way of doing this, or at least a "best practice" method to use?
For my money, the best general purpose approach to this issue is to use the django-pagination utility. It's incredibly easy to use and your URLs should have the format you desire.
I prefer to use the GET URL parameter, as in URL?pg=#. It's very common and provides a standard visual clue to users about what is going on. If, for instance, I want to bookmark one of those pages or make an external link, I know without thinking that I can drop the pg parameter to point at the "latest" front-page index. With an embedded #, this isn't as obvious... do I leave off the parameter? Do I always have to set it to 1? Is it a different base URL entirely? To me, having pagination through the GET parameter makes for a slightly more sensible URL, since there's an acceptable default if the parameter is omitted and the parameter doesn't affect the base URL.
Also, while I can't prove it, it gives me the warm fuzzy feeling that Google has a better chance at figuring out the nature of that page's content (i.e. that it is a paginated index into further data, and will potentially update frequently) versus a page # embedded inside the URL, which will be more opaque.
That said, I'd say this is 99% personal preference and I highly doubt there's any real functional difference, so go with whatever is easier for and fits in better with your current way of doing things.
EDIT: Forgot to mention that my opinion is Django specific... I have a few Django apps so I'm relatively familiar with the way they build their URLs, and I still use a "pg" GET parameter with those apps rather than embedding it in the URL directly.
It seems like there are two things going on. A static page, that won't change and can be used for permalinking, like an article, as well as a dynamic page that will update frequently. There is no reason you cannot use both. URL rewriting should allow this to work quite nicely. There's no reason to let the implementation control the interface, there is always at least one way to skin every cat.