人工智能(AI) VS 商業(yè)智能(BI) 區(qū)別與聯(lián)系是什么？
你可能也喜歡這些API文章!
GROUP BYGROUP BY與括號方法類似，您可以設(shè)計一個 API 將運(yùn)算符置于 RHS（而不是 LHS）上。例如，將查找價格大于或等于 10，但小于或等于 100 的所有商品。 GET /items?price=gte:10&price=lte:100
GET /items?user_id=gt:100如果您需要在端點(diǎn)上進(jìn)行搜索，您可以直接使用搜索參數(shù)添加對過濾器和范圍的支持。如果您已經(jīng)在使用 ElasticSearch 或其他基于 Lucene 的技術(shù)，您可以直接支持 Lucene 語法或 ElasticSearch 簡單查詢字符串。
例如，我們可以搜索包含術(shù)語 red chair 且價格大于或等于 10 且小于或等于 100 的商品： GET /items?q=title:red chair AND price:[10 TO 100]
此類 API 可以允許模糊匹配、增強(qiáng)某些術(shù)語等等。
大多數(shù)返回實(shí)體列表的端點(diǎn)都需要某種分頁。
如果沒有分頁，簡單的搜索可能會返回數(shù)百萬甚至數(shù)十億的點(diǎn)擊量，從而導(dǎo)致額外的網(wǎng)絡(luò)流量。
分頁需要隱式排序。默認(rèn)情況下，這可能是項(xiàng)目的唯一標(biāo)識符，但也可以是其他有序字段，例如創(chuàng)建日期。
這是最簡單的分頁形式。限制/偏移在使用 SQL 數(shù)據(jù)庫的應(yīng)用程序中變得流行，這些數(shù)據(jù)庫已經(jīng)將 LIMIT 和 OFFSET 作為 SQL SELECT 語法的一部分。實(shí)現(xiàn)限制/偏移分頁只需要很少的業(yè)務(wù)邏輯。
限制/偏移分頁看起來像。此查詢將返回從第 100 行開始的 20 行。 GET /items?limit=20&offset=100
（假設(shè)查詢按創(chuàng)建日期降序排序）
GET /items?limit=20GET /items?limit=20&offset=20GET /items?limit=20&offset=40作為 SQL 語句，第三個請求如下所示：
SELECT
*
FROM
Items
ORDER BY Id
LIMIT 20
OFFSET 40;GET /items?offset=0&limit=15GET /items?offset=15&limit=15 GET /items?offset=25&limit=15即使有限制，偏移分頁也很容易實(shí)現(xiàn)和理解，并且可以用于數(shù)據(jù)集上限較小的應(yīng)用程序。
鍵集分頁使用最后一頁的過濾器值來獲取下一組項(xiàng)目。這些列將被索引。
（假設(shè)查詢按創(chuàng)建日期降序排序）
GET /items?limit=20GET /items?limit=20&created:lte:2021-01-20T00:00:00GET /items?limit=20&created:lte:2021-01-19T00:00:00SELECT
*
FROM
Items
WHERE
created <= '2021-01-20T00:00:00'
ORDER BY Id
LIMIT 20鍵集分頁對于具有單個自然高基數(shù)鍵的數(shù)據(jù)非常有效，例如可以使用時間戳的時間序列或日志數(shù)據(jù)。
查找分頁是鍵集分頁的擴(kuò)展。通過添加 after_id 或 start_id URL 參數(shù)，我們可以消除分頁與過濾器和排序的緊密耦合。由于唯一標(biāo)識符本質(zhì)上是高基數(shù)，因此我們不會遇到與按低基數(shù)字段（如狀態(tài)枚舉或類別名稱）排序不同的問題。
基于搜索的分頁的問題是當(dāng)需要自定義排序順序時很難實(shí)現(xiàn)。
（假設(shè)查詢按創(chuàng)建日期升序排序）
GET /items?limit=20GET /items?limit=20&after_id=20GET /items?limit=20&after_id=40尋求分頁可以被提煉成一個子句 where
SELECT
*
FROM
Items
WHERE
Id > 20
LIMIT 20如果按 id 排序，上面的示例可以正常工作，但如果我們想按電子郵件字段排序怎么辦？對于每個請求，后端需要首先獲取標(biāo)識符與 after_id 匹配的項(xiàng)目的電子郵件值。然后，使用該值作為過濾器執(zhí)行第二個查詢。 where
讓我們考慮一下查詢，后端將需要兩個查詢。第一個查詢可能是使用哈希表進(jìn)行 O(1) 查找，以獲得電子郵件數(shù)據(jù)透視值。將此輸入到第二個查詢中，以僅檢索電子郵件位于 after_email 之后的項(xiàng)目。我們按電子郵件和 ID 兩列進(jìn)行排序，以確保在兩封電子郵件相同的情況下有穩(wěn)定的排序。這對于較低基數(shù)字段至關(guān)重要。 GET /items?limit=20&after_id=20&sort_by=email
1.
SELECT
email AS AFTER_EMAIL
FROM
Items
WHERE
Id = 202.
SELECT
*
FROM
Items
WHERE
Email >= [AFTER_EMAIL]
ORDER BY Email, Id
LIMIT 20Seek 分頁是一個很好的整體分頁策略，也是我們在 Moesif Public API 上實(shí)現(xiàn)的。它需要在后端進(jìn)行更多的工作，但確保不會給 API 的客戶端/用戶增加額外的復(fù)雜性，同時即使在更大的搜索范圍內(nèi)也能保持性能。
與過濾一樣，排序?qū)τ谌魏畏祷卮罅繑?shù)據(jù)的 API 端點(diǎn)來說都是一項(xiàng)重要功能。如果您要返回用戶列表，您的 API 用戶可能希望按上次修改日期或電子郵件進(jìn)行排序。
為了啟用排序，許多 API 添加了 sort 或 sort_by URL 參數(shù)，該參數(shù)可以將字段名稱作為值。
然而，良好的 API 設(shè)計可以靈活地指定升序或降序。與過濾器一樣，指定順序需要將三個組件編碼為鍵/值對。
GET /users?sort_by=asc(email) 和 GET /users?sort_by=desc(email)GET /users?sort_by=+email 和 GET /users?sort_by=-emailGET /users?sort_by=email.asc 和 GET /users?sort_by=email.descGET /users?sort_by=email&order_by=asc 和 GET /users?sort_by=email&order_by=desc不建議使用排序和順序不配對的最后一種設(shè)計。您最終可能允許按兩列或更多列排序：
SELECT
email
FROM
Items
ORDER BY Last_Modified DESC, Email ASC
LIMIT 20要編碼此多列排序，您可以允許多個字段名稱，例如
GET /users?sort_by=desc(last_modified),asc(email) 或
GET /users?sort_by=-last_modified,+email
如果排序字段和排序不配對，則需要保留 URL 參數(shù)排序；否則，什么排序應(yīng)該與什么字段名稱配對是不明確的。然而，許多服務(wù)器端框架在反序列化到映射后可能不會保留順序。
您還必須確保任何緩存鍵都考慮 URL 參數(shù)排序，但這會給緩存大小帶來壓力。
良好的 API 設(shè)計是開發(fā)者體驗(yàn) (DX) 的關(guān)鍵組成部分。 API 規(guī)范可以比許多底層服務(wù)器實(shí)現(xiàn)更持久，這需要考慮 API 的未來用例。
原文鏈接：REST API Design: Filtering, Sorting, and Pagination
人工智能(AI) VS 商業(yè)智能(BI) 區(qū)別與聯(lián)系是什么？
使用 RESTful API 探索藝術(shù)世界
鍵.png)
如何在Java、Python、GO程序中使用AI人臉識別API接口
什么是API產(chǎn)品經(jīng)理？
基本 API 設(shè)計模式：打造卓越 Web 服務(wù)的指南
2024 年值得考慮的 12 種最佳 API 監(jiān)控工具
關(guān)于API令牌你需要知道的一切
經(jīng)濟(jì)動蕩期，開發(fā)者如何用API平臺提升個人競爭力！
API 設(shè)計優(yōu)先：增強(qiáng)您的開發(fā)過程