1, API interface design--preface

1. Scene description

For example, we want to make an app that needs to provide data to the app via API interface. Let's say we do the mall, like we sell books. We can imagine what the app is about:

1) Home: Banner Area (can be some of the most popular books to promote), this week's Hot book area, the book area of this month's high praise, the book area discount activities ...

2) Leaderboards: such as the first quarter Hot List, new book version ...

3) Book list: Manage the list of books added by the background operations, such as the "programmer from Start to quit" series book ...

4) User-related: such as user personal information settings, order management, message management, collection of books ...

Data is stored in the database, taking into account the bottleneck of high concurrency database, the server architecture with db+ cache.

2. Summary of important interfaces

Seemingly simple app, need to call API interface is very much, summed up under a few kinds of interfaces:

1) List interface: For example, book list in books, List of books in the leaderboard;

2) Details of the interface: the detailed information of the book;

3) Comment Interface: Book review (here may ask for a purchase of the ability to comment), star sign;

4) Like the interface: to the book to praise, to the book to praise;

5) Collection Interface: Collection of books, collection of books;

6) "related" interface: such as the book "PHP from the introduction to the abandonment" related to what books;

7) Focus on the interface: Focus on a book or book author, once a book has a discount or the author has a new book, will push the news and so on. Or the user is concerned about each other;

8) Publishing Interface: For example, users can publish a book list. A user published a book, B users can focus on a user, a user to publish a new book, will give B users to push messages and so on;

9) Search Interface: Query books, inquiry form, query users and so on

3. Backstage Management System

1) Source of book information: Crawler crawl data, operators in the management background add;

2) book price, inventory and other information, can be set up in the background;

3) The classification of books, the label of books, such as reptiles if not crawled, operations can be manually set;

4) Sorting of books: In the management background settings, used in the app to show the order;

5) Book Management: Operations can be added, can be set to show/hide, the user submitted a book, in the background to audit;

6) User's comments: in the background audit;

Note: The management system also has many functions, the simple first writes these several.

4. Database design

1) Books table book

• ID self-increment ID, primary key, book ID
• Title Caption
• Description description
• author_id Author ID
• SOURCE Crawler sources
• Stock Inventory
• Price
• Status: Shelves/Bottom Shelf
• Sort order
• Create_time Add Time
• Create_user Add-on (operating account ID, crawler to specify an operating ID)
• Update_time modification Time
• Update_user Modified By

2) Author Table book_author

• ID self-increment ID, primary key, author ID
• Name author pseudonym
• Birthday Birth date
• Sex gender
• Description description

3) Classification Table Book_category

• ID self-increment ID, primary key, category ID
• PARENT_ID Parent class ID, the parent class ID of the top-level classification is 0
• Title Category name
• Status state is available
• Create_time Add Time
• Create_user Add-on (operating account ID)
• Update_time modification Time
• Update_user modified by (Operating account ID)

4) Books and classification relations table Book_category_relation

(Books are bound to the finest classification, for simplicity, suppose a book binds only one category, assuming that books and classifications are many-to-one relationships)

• BOOK_ID PRIMARY Key
• cate_id
• Create_time Add Time
• Create_user Add-on (operating account ID)
• Update_time modification Time
• Update_user modified by (Operating account ID)

5) Label Table Book_tags

Reference classification Table

6) Book and label relationship table Book_tags_relation

Refer to books and taxonomy tables for simplicity, suppose that books and categories are many-to-one, a label has multiple books, and a book has only one label.

7) book List book_list

• ID self-increment ID, primary key, book ID
• Title Book name
• Description description
• Status state: Publish/Hide
• Audit_status Audit Status
• Audit_reason Audit reasons (required when audit failure)
• Audit_time Audit Time
• Audit_user Auditor (Operational ID)
• Create_time creation Time
• Create_user Creator (operation or user ID)
• Update_time modification Time
• Update_user (operation or user ID)

8) Book contents list (books included in book) Book_list_content

• ID self-Increment ID
• LIST_ID Book ID
• BOOK_ID Book ID
• Reason recommended reasons
• Star Recommended stars
• Status: Show/Hide
• Sort order
• Create_time Add Time
• Create_user added by
• Update_time modification Time
• Update_user Modified By

9) User table users

• ID self-increment ID, primary key, user ID
• User_name User name (login)
• Nickname User Nickname
• Email email
• Password login Password
• Phone number
• Sex gender
• Avatar Avatar
• Description Personality Description
• Status: Pending Activation/Enabled/blacklist
• Create_time Account creation Time

10) The book likes the table Book_like

• ID self-Increment ID primary key
• BOOK_ID Book ID
• USER_ID User ID
• Status is valid (because the data is not deleted, so increase this state field)
• Create_time likes time
• Update_time Update Time

11) Book Collection table Book_collect

Refer to a book like a table

12) User concern table (User A is concerned about User B) User_focus

• ID self-Increment ID primary key
• USER_ID User ID (User a)
• TARGET_USER_ID User ID that is being followed (User B)
• Status is valid
• Create_time Focus Time
• Update_time Update Time

Note: User A and User B are concerned with each other, and there are 2 data in the table

13) Orders Form order

• ID self-increment ID order ID
• ORDER_SN Order Number
• USER_ID User ID
• coupon_id Coupon ID
• Discut_money Discounted price
• Origin_money Original Price
• Money Order Total Price
• Status Order statuses: Pending payment/Paid/pick complete/shipped/returned/received ...
• Comment User Notes
• Reason return reasons, etc.
• Create_time Order generation Time
• Update_time modification Time

14) Order Contents Table Order_content

• ID self-Increment ID primary key
• order_id Order ID
• BOOK_ID Book ID
• Num number
• Price prices, original price
• Amount Total Price
• Discut_money Discount Price
• activity_id activity ID (Discount for events)

15) Comment Form book_comment (for the sake of simplicity assume that comments are only comments on the book, no reply to the comments)

• ID self-Increment ID primary key
• BOOK_ID Book ID
• USER_ID User ID
• Star stars
• Content comments
• Create_time creation Time
• Status state: Available/deleted
• Update_time modification Time
• Audit_status Audit Status
• Audit_reason reason for audit failure
• Audit_time Audit Time
• Audit_user Auditor (Operational ID)

16) Manage the background operation table operation

• ID self-Increment ID primary key
• USER_ID Operating Account ID
• Content contents
• Operate_time operation time

Note: In fact, there are not so many tables, for the sake of simplicity, for the time being the list is listed first.

5. Cache Design

will be explained in detail in each API interface.

6. API Interface Design Idea

Considering the bottleneck of the database at high concurrency, the results of the request need to be cached. The strategy here is:

1) Get the data from the cache, the data in the cache is returned directly, or simply processed and then returned;

2) The cache has no data, the data is looked up from the DB, and then the cache is written back, which is called "back source."

3) The cache key is required to set the expiration time, to avoid the data always occupy memory;

4) Expiration time of the design, it is best to disrupt, avoid the same time there are a large number of key expiration resulting in the request to centralize the DB request caused by avalanche;

5) According to business requirements, "back to the source" when the request to cache lock requests to the database to obtain data and update the cache, other requests sleep for a period of time (such as 5 milliseconds 10 milliseconds) and then to cache the request, if the request or no data, you can continue to wait or directly return empty data.

6) There is no need to cache up the fields, do not cache;

7) The app does not need to use the field is not necessary to return to the app, such as the review of the review time, reviewers, returned to the app is useless, because the data does not need to be displayed, will not be used;

8) Reduce the number of API requests, such as multiple requests, to see whether the merger, such as the home page, there are several areas, each region has several data. Of course, multiple requests can be implemented, but with fewer requests, the server can accept more requests from clients.

1, API interface design--preface