How to fetch document list and category from the front-end

The front desk needs to retrieve the document list and categories, how should the interface be called? The sequence is 'first categories, then list, and finally details': first, fetch the category tree and tag list once and place them in the cache, then use the list interface with classification identifier and pagination parameters to fetch pages, and use the detail interface to fetch the main content and custom fields when the user clicks on a specific data item. The advantage of this sequence is that the requests can be reused, and the homepage and column pages will not make multiple API calls due to the need to refresh the category on each screen. The document list, details, categories, and tags belong to the high-frequency API call capabilities provided by the backend, and the specific parameters can be checked in the interface document.

List the data to be retrieved first

Write the calling code before listing the data needed for the page in a table, to avoid adding requests directly in the template.

Order of calling list and detail

There are three common mistakes in list interfaces. The first is to retrieve all fields: on the list page, only the title, summary, and time are needed, and the main content and custom fields are left to the detail interface, the fewer fields per page, the faster the response. The second is to not include category conditions in the pagination parameters, and when you turn to the second page, data from other columns will also be brought out. The third is to use the detail interface as a list, and if you send 20 requests for a page of 20 items.

The details interface returns fields on a document basis, the extracted custom fields can be directly rendered into the specification table; at the same time, pay attention to the status field: formal documents and drafts, and pending release have different visibility ranges, the draft link contains a preview parameter for preview, and the front-end list should default to taking formal documents. The content in the recycle bin does not participate in the list, and the formal documents mistakenly deleted can be restored from the recycle bin without going through the interface.

How do categories and tags relate

Categorize the column level, tags express horizontal themes, both can be used as filtering conditions for list interfaces. The front-end usually needs both 'articles under a certain category' and 'which categories and tags an article belongs to', the former uses category identification to filter, and the latter reads the associated fields returned by the details. It is recommended to retrieve the entire category tree at one time according to the level, and the front-end assembles the breadcrumbs itself; when there are many tags, first take the popular tags, and then load the list under the tags according to user clicks, to avoid loading all the data at once on the homepage.

Check for duplicates before batch writing.

The interface is not only for reading but also for writing. When migrating content or batch supplementing, first query whether the document exists by title, and then decide whether to create or update, which is the conventional usage of the import interface: the document content is imported through the /api/import/archive entry, import is responsible for writing, and archive side supports querying whether it exists by title, and using it for 'query first, then write' can avoid the same article appearing twice.The batch import itself supports two sources: compressed packages and tables. The field mapping should be confirmed before import: which columns correspond to the title, category, tags, body, and abstract, and misalignment in mapping is harder to discover than import failure.

After writing, confirm three things: whether the front-end list can get new content, whether the fields returned by the detail interface are complete, and whether the site map and push cover the newly added address. It is recommended to place batch operations during off-peak hours, do not pour too much at a time, and check in batches to make it easier to locate errors.

Common questions

Does the interface require login?The interface for reading public content does not need it; for the call of write-type, it needs to be authenticated according to the background configuration, and the credentials are only placed on the server, do not expose them to browser scripts.

Can pagination and filtering be used at the same time?Yes, you can pass the parameters together. Note that when flipping pages, keep the filtering conditions unchanged, otherwise, there may be repeated items or missing items between pages.

Can the front-end directly retrieve all articles and perform its own filtering?It is okay for a small amount of content, but when the content exceeds a thousand, the filtering conditions should be sunk to the interface parameters, filtered by the server, otherwise the transmission and rendering of the first screen will slow down.

Is the content written by the import interface a draft or formal?It depends on the draft tag passed when the call is made. Write it as a draft first, check the layout and fields, and then release it, which is safer than publishing directly.