For database-backed web applications, the Details Page is the fundamental web application /https://blog.lunatech.com/2005-11-21-navigation-patterns[navigation design pattern]. A Details Page provides a mechanism for both presentation and selection, and may be the focus of a data-centric site’s structure.
For example, consider a hypothetical web site about cafes, that contains editorial reviews, photos and reader comments. On the cafe site, a cafe is the fundamental unit of navigation - the table in the centre of the data model, if you like. Similarly, the cafe Details Page is the central navigation unit for each cafe.
The cafe Details Page provides a mechanism for presentation in the sense that this page presents all available data about the cafe, or at least directly links to it. This is pretty obvious, but the important thing is that if you consistently use a Details Page as a placeholder for all information then the reader knows that there is no need to look elsewhere.
If there is too much to display on a sinlge page, then tabs are often a good way of splitting a Details Page into several web pages, while retaining a sense that the group of pages is a single navigation unit.
For example, a cafe's Details Page primarily identifies a cafe by name, address and photo. In addition, this page presents (links to) the cafes reviews and discussion forum. There may, of course, be a separate navigation structure for all of the discussion forums but it still makes sense to provide a direct link to a specific cafe's forum, once the user has already 'selected' it by navigating there. Not including the link would be like a product page on the manufacturer's web site that lacks a direct link to the product's support page, which is unfortunate because the product's main Details Page is usually easier to find. This is unfortunately common.
Many web applications have functionality that involves selecting an item and performing an action, such as buying it or editing its data. If you have a standard Details Page for each item, you can include standard action/command links for operations on that item.
This approach scales better to many items than the form-based approach where you select items from a pick list. For example, a 'select airport' pick list might work for major airports in a small country, but not for all airports and airstrips world-wide. In the latter case you would need page-based search and browse interfaces to support many ways of finding one airport among thousands, and a Details Page for each one that includes enough information to differentiate two airports with similar names that would be indistinguishable on a pick-list.
This use of Details Page as selection is often obvious. However, if you are thinking in terms of desktop GUI applecations then selection works at the previous level of navigation. You don't delete a filesystem folder/directory by opening (navigating to) it and then choosing 'Delete'. Instead you select the folder within a list of files and folders in the same location and then choose 'Delete'. In a web application, this would correspond to using a radio button next to an item in a list for selection, so that you select one item from a list without navigating to the item. Note that this is the approach you need if you want to support multiple selection, because you can then use checkboxes instead of radio buttons; selecting a Details Page by navigation does not support multiple selection because you cannot be in two places at once, according to the conventional web application model.
Navigation - Item Links
Linking from an item's name to its Details Page is a natural way of adding relationship-based navigation, where links correspond to database relationships, allowing easy navigation to related information. For example, on IMDB, each film's page lists actors' names as links to each actor's Details Page, which in turn lists films as links to film Details Pages. Similarly, the cafe web site could list to the street where the cafe is, for a list of nearby cafes, or to an overview of the type of cafe.
Once you have standard Details Pages, it makes sense to have a standard Item Link to each one. This is easy, provided that each item has a clear 'name', to use as the link text. This becomes harder when the name is not unique - on the cafe web site, each link might need to be of the form cafe name (street address). Similarly, IMDB adds the year of each film to its Item Link. In any case, once you have a standard kind of Item Link, significant benefits accrue from using it consistently.
The elegance of this kind of navigation is that, if used consistently, it requires no additional user-interface elements. This is hypertext as it should be, with intuitive linking. However, many web applications are still so busy trying to copy the desktop applications they have replaced that they completely separate content and navigation, failing to take advantage of the medium.