20

We have two pages. One is a landing page, given by the route /region. The other is a detail page for a particular region, given by the route /region/summary/{id}. The landing page is the normal way by which a user would navigate to a detail page.

Suppose a user visits the intermediate route region/summary. Should he be redirected to a 404 page, since technically it's not a valid route, or redirected to the region page, since the main problem is that he didn't provide an id in the route, and he'd find valid links everywhere on the landing page?

JohnGB
  • 68,376
  • 26
  • 180
  • 294
Peter Majeed
  • 303
  • 1
  • 7
  • What would the {id} represent? User, specific content, or something else? – JohnGB May 07 '13 at 17:29
  • The {id} is the id of the region in the data store. (Ideally, it'd be followed by a friendly url slug.) – Peter Majeed May 07 '13 at 17:30
  • possible duplicate of Generic or dedicated error pages – ChrisF May 07 '13 at 17:33
  • 1
    @ChrisF It doesn't look like a duplicate to me. This question is about whether you should redirect to an existing page that could be accessed in the normal usage of the site. That other question is about whether you should create a custom error page. – Graham Herrli May 07 '13 at 18:56
  • @3nafish if no one else agrees the close vote will decay after a few days, so there's no harm done. – ChrisF May 07 '13 at 18:58
  • 1
    @ChrisF I know. I just posted my reasoning as to why it shouldn't be closed so that anyone else reviewing the close vote queue would be able to take that opinion into account. – Graham Herrli May 07 '13 at 19:02
  • 1
    Why isn't the summary at region/{id}? I mean, it sort of means "get me region information about {id}", which in your cause means the summary - unless there's another "base" page for each region, in which case, I'd suggest region/{id}/summary, so each level of the URL is still valid. – Izkata May 07 '13 at 20:01
  • 3
    Why have summary in the URL at all? I'd do /region and /region/{id}. – josh3736 May 07 '13 at 20:04
  • @Izkata: Because there are a few things you can do with a region besides get a summary. There are other routes that follow the pattern /region/{action}/{id}. – Peter Majeed May 07 '13 at 20:53
  • @josh3736: Looks like you and Izkata are on the same page. See my response above. – Peter Majeed May 07 '13 at 20:53
  • 3
    So /region/{id} is the summary, and then have /region/{id}/{action}. Makes more sense semantically. – josh3736 May 07 '13 at 20:56
  • @PeterMajeed Well, my second suggestion, then - region/{id}/summary, with region/{id} going to some sort of info page. Think of it this way: {region}/{action}. – Izkata May 07 '13 at 20:58
  • @Izkata: still stewing on your suggestion. If you want to put all that thought into an answer, you'd probably have at least my upvote. – Peter Majeed May 07 '13 at 21:57
  • @josh3736: ditto above. – Peter Majeed May 07 '13 at 21:57

4 Answers4

12

This was originally a comment, because I had assumed it was considered and not used prior to this question being posted..

At the moment, these are your URLs (with "summary" being a type of action, presumably):

/region
/region/{action}/{id}

Your question is, what should you do if someone tries to access it without an ID, like this:

/region/{action}

I say: Don't allow it in the first place, and shape your URLs conceptually like this:

/region
/region/{action}
/{region}
/{region}/{action}

So with this mapping: {region} -> region/{id}, you get the URLs:

/region
/region/{action}
/region/{id}
/region/{id}/{action}
  • /region would still go to the same place you intend; a landing page.
  • /region/{id}/summary does the same thing as your /region/summary/{id}
  • /region/{id} basically would mean "Get me information about Region {ID}", which could either 302 to /region/{id}/summary, or just return that page.
  • Likewise for /region/summary - the user is asking for information about the landing page. It should return the same thing as /region (or 302 to it, or /region should 302 to here).

RESTful URLs like this are used in web APIs, and they're pretty intuitive, making it a good model for sites that can use them.

Two more sets of examples from the StackExchange API (which, granted, doesn't include /tags/{tags}):

/badges                   Get all badges on the site, in alphabetical order.
/badges/{ids}             Get the badges identified by ids.
/badges/recipients        Get badges recently awarded on the site.
/badges/{ids}/recipients  Get the recent recipients of the given badges. 

/tags                   Get the tags on the site.
/tags/{tags}/info       Get tags on the site by their names.
/tags/synonyms          Get all the tag synonyms on the site.
/tags/{tags}/synonyms   Get the synonyms for a specific set of tags.

And one from this Edit Answer page (which, unfortunately, doesn't work without /edit...):

http://ux.stackexchange.com/posts/39273/edit
Izkata
  • 522
  • 3
  • 6
8

I think it's ok to make guesses about where your users were trying to go, but always provide the correct HTTP response code to indicate that the item was not found or was "Permanently Moved" and consider showing a simple message on the page in case the user really was trying to go somewhere they thought was legitimate and are confused why you redirected them.

sirtimbly
  • 2,033
  • 14
  • 18
3

I would argue that if you have the ability to fall back to a page that may be useful, you should do that rather than give a 404 error.

In your example, falling back to /region when someone enters /region/summary gives the user the opportunity to select what they may have been looking for. This interrupts their flow much less than it would have if you have given them a 404 error page, and presents them with a better UX.

When you are working with people, you should consider the intent of the user and be as flexible as you can. With machines, it's more about being precise, and that is where you should give an error instead of falling back to the closest information that you have.

On the other hand if they gave a wrong {id}, you should revert to a 404 error page with the most useful information that you can offer.

JohnGB
  • 68,376
  • 26
  • 180
  • 294
2

404 Errors can be really helpful.

Everyone wants their sites to be intuitive and every user strives to do less work. With that being said the 404 errors in your statistics and logs can help you to determine where the shortcomings of your user interface reside. If the user interface is so bad from a user experience standpoint that the users are trying to "skip" using the interface, then there is a need for revision. Google and search engines should not typically reach a 404 error on your site, since they only follow hard links. In the backend of Google's webmaster tools they do provide feedback as to whether or not they found a bad or dead link on your website and you can search Google to determine where it came from.

If you blindly give someone a 301 [permanent] redirect that presents them with the wrong information, there is the risk that you will drive site visitors away. If you redirect all traffic to the landing page in the event they tried to access a page that did not exist they have no way of knowing if it was their own mistake, if the page no longer exists, or worse if the site is broken.

I have found it useful to parse the request to show likely links that the visitor was intending. The these are presented in a list as a 300 redirect indicating some other action is necessary since multiple actions could potentially be taken. If there are no records even remotely on topic for the request then I provide a 404 error because I do not want the search engines or visitors to relate my site with the failed query, keywords, or context. This can help to keep traffic on the site as well as inform search engines that there are related items in your site.

AbsoluteƵERØ
  • 741
  • 3
  • 7