We're looking at going a little more restful in our URL scheme and for the most part it make sense to us. The one thing we can't find a good example of is how do you handle a separate search screen? We need to show a list of cards to the user but they always need to do a search first.
Any ideas or examples out there?
You can treat Search as RESTful resource ...
Ryan Bates explains the pattern here: http://railscasts.com/episodes/111-advanced-search-form
This fit the bill?
I'd set up a scope in in my model class that does the search you want; just add a lambda to the scope so you can pass in the search term, should look something like this:
scope :matching_attribute, lambda{|your_search_term| where(:model_attribute => your_search_term)}
and then in your controller's index, just check for the request param (whatever you're naming it) and do the appropriate thing there
Related
I have a pretty long edit form, and I would like to split it into separate sections. Say, I want to take out the user photo gallery and maybe address details into a separate view. My question is - what is the best practice to do that?
I assume my link should be looking like post/23/edit/gallery or post/23/edit/address would it be the Rails way? what kind of route does this require?
Thank you!
post/23/gallery/edit looks more semantic. gallery - resource related to post and edit - action on this resource. actual modification will have post/23/gallery url with POST, PUT, DELETE methods, which is more REST
I'm working on a new advert website and want to implement some good SEO URLs.
I got category URLs like:
/category
/category/sub-category
This seems ok. What about detail pages?
Option 1:
/announcements-and-notices/announcements-various/15880/suscipit-dis-molestie-malesuada-vestibulum-ut.html
Option 2:
/adverts/15880/suscipit-dis-molestie-malesuada-vestibulum-ut.html
In reality my website has a pretty long URLs due to multiple areas you can shop. So it would become:
/en/area-name/announcements-and-notices/announcements-various/15880/suscipit-dis-molestie-malesuada-vestibulum-ut.html
/en/area-name/adverts/15880/suscipit-dis-molestie-malesuada-vestibulum-ut.html
Which detail page would be a better URL? The first option seems to be better if the product has no long/good title. The second seems better as its the most relevant one and shortest especially with long category names.
I would like to hear your thoughts!
EDIT:
I found this two google docs:
http://www.google.nl/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDYQFjAA&url=http%3A%2F%2Fwww.google.com%2Fwebmasters%2Fdocs%2Fsearch-engine-optimization-starter-guide.pdf&ei=lXyaT6T_L8zR4QSM4c2qDw&usg=AFQjCNEMj8KHxhxQz9cMLoMxMDiLdrAbJw
http://support.google.com/webmasters/bin/answer.py?hl=en&answer=76329
I think I will be going for /adverts. Anyone disagree?
i have seen many of SEO analysts miss something about optimizing their webpage and that is your page will be optimized for only some keywords not all keywords. it is not important how length is your URL. you should first analyze whether the contents in your webpage is rich enough to have such URL with these keywords or not. if the answer for every keyword is yes then the more length will give you the more rank.
I think you can even set your pages up in a way to use only the slug and skip the id, such as:
/adverts/suscipit-dis-molestie-malesuada-vestibulum-ut
or even just:
/suscipit-dis-molestie-malesuada-vestibulum-ut
like this and refer straight to the adverts controller and the advert itself, which has this slug assigned to it (the one with id 15880).
This way you'll have nice and clean URLs. Just assign and keep an unique slug for each advert and handle it using .htaccess, or dynamically inside the code of your site, if the system allows it.
Cheers.
I'm building a site that has items, with each item having a page, for example:
website.com/book/123
website.com/film/456
website.com/game/789
Each item can have multiple sub (and sub-sub, sub-sub-sub) pages, for example a book could have a blurb, a film could have a gallery and a game could also have a gallery.
My question is, does any sort of standard or best practice exist around structuring the URLs for pages associated with an item? For example:
website.com/film/456/gallery
Where the sub page comes after the item, or:
website.com/film/gallery/456/
where the item is the very last part of the URL.
Does anyone have any information on why which approach is best or if any web standard exists? It seems an obvious thing but I'm struggling to decide, I can think of pros and cons for each approach -- although I'm leaning towards the former option because it means the following user path would match the URL:
load website.com -> click "films" (website.com/films)-> click "a film" (website.com/film/123) -> click gallery (website.com/film/123/gallery)
but something about it seems... off, inconsistent maybe.
You are correct that the former URL is "better" and is more widely deployed. I don't think you would find this documented in any standard; it is rather more of a convention. Most articles and books covering REST do it that way.
The reason for this is, as you say, that the path components in the URL match the structure of resources and sub-resources. In particular, all of the following should be valid URLs:
website.com/
website.com/books
website.com/books/123
In particular, note that it is books/123, not book/123 like you have. I have seen the singular but IMHO the plural is better.
For the URL /books
a GET gets all books, but you can restrict the books with query parameters, e.g. /books?author=alice
a POST adds a new book (with a server-generated id).
For the URL /books/123
a GET gets that particular book
a PUT replaces the book with that id (or adds a book with that client-generated id)
Now if a book has blurbs and the blurbs are unique only to a particular book then you will add the following URLs:
website.com/books/123/blurbs
website.com/books/123/blurbs/72
You can do the same for films and galleries, provided each gallery belonged to a single film. But if galleries existed for multiple films, then you would make /galleries a top-level URL. Navigating from a film to a gallery would still be fine. You wouldn't have a structured URL. You would instead get all galleries containing pictures from film 456 via a GET to
website.com/galleries?film=456
The general rule is that if you have an ownership relation for the subresources you can use structured urls, but if there is a looser relationship among top-level items, query parameters are fine. Don't fall into the common misconception that RESTful URLs don't have query parameters; they do. :)
Now finally, to directly answer your question: website.com/films/galleries/456 is not a good URL IMHO because `website.com/films/galleries/ is not very useful. In fact I think it is rather ugly. What would it mean? All galleries? If so, it should be website.com/galleries.
Again I don't think this is standardized anywhere, but it feels very common and conventional.
What's the best way to implement an interface that looks like this in rails?
Currently I'm using Searchlogic, and it's a tad painful. Problems include:
Making sure certain operations remain orthogonal -- for example, if you select "Short Posts" and then search, your search results should be restricted to short posts.
Making sure the correct link gets the "selected" class. Right now the links are <a>'s, so maintaining this state client-side is tricky. I'm hacking it by having the AJAX response to, say, sorting return a new sort links section with the correct link "selected". Using radio buttons instead of <a> tags would make it easier to maintain state client-side -- maybe I should do that?
I recently solved a similar problem using named_scopes and some ruby metaprogramming that I rolled up into a plugin called find_by_filter.
find_by_filter accepts a hash of scope
names and values, and chains them into
parametised scope calls. If the model has a named_scope that matches the provided name, this is called.If no named_scope is found, an anonymous scope is created.
Why is this:
http://MySite.com/Project/24/Search/32/Edit/49
preferred over this?
http://MySite.com/Project/24?Search=32&Edit=49
I'm not sure where your premise is coming from? It looks like an artificial example, which makes it hard to comment on.
A better comparison would be something like:
http://MySite.com/Project/24/Members/Edit
As opposed to:
http://MySite.com/Projects.aspx?id=24§ion=Members&action=Edit
Where, among other things, the hierarchy of entities is immediately obvious from the first example (ie, a Project contains Members). It also suggests that you can use other URLs that contain similar structures to the first (ie, /Projects/24 and /Projects/24/Members), so in that sense it's more concise.
If it comes down to actions that have a variable number of parameters, such as searching, then it's totally fine to use URL parameters as this will give you more flexibility, eg:
http://MySite.com/Projects/Search?name=KillerApp&type=NET
You could construct a URL using the first style, but you don't really gain anything, and managing the route could add unnecessary overhead:
http://MySite.com/Projects/Search/name/KillerApp/type/NET
I would argue that this (or any similar construction, eg if you removed the param names) suffers from an artificial hierarchy - the action in this case is really Search, and everything else is just a parameter of the Search, so it's in the same hierarchy, not some "sub" hierarchy.
Not really a fair comparison. The style allows you to drop the GET parameter names, so the routed one should read something like
http://MySite.com/Project/24/32/49
It's really an aesthetic improvement, though -- it's both neater-looking, and easier to type or read out to someone.
Its mostly a human readability issue, although (since most search engine ranking algorithms are not publically disclosed), it is believed to have SEO value as well.
In the example case, it may not be any better. But it's a Search Engine Optimization in general. Here are some SEO best practices -- from that article ...
Ideally, the URL structures should be
static, and reveal what the page is
about. A simple and clear URL
structure is much easier for both
search engine spiders and human
beings.
Easier to remember as well. It's easier for a user to remember /Employee/1 to get the information for employee #1 rather than understand a querystring. Not a reason to use it but I think its a small improvement.