Tag: json

Problem Details for HTTP APIs (RFC 7807 變成 RFC 9457)

之前寫過「RFC 定義的 application/problem+json (或是 xml)」，最近在找資料發現 2016 年的 RFC 7807 被 2023 年的 RFC 9457 取代了，兩份的標題都是「Problem Details for HTTP APIs」。

在「Appendix D. Changes from RFC 7807」這邊有提到做了什麼修改，看起來有三點：

Section 4.2 introduces a registry of common problem type URIs
Section 3 clarifies how multiple problems should be treated
Section 3.1.1 provides guidance for using type URIs that cannot be dereferenced

看起來大骨架沒有變，主要是補充了一些不足而已...

OpenAI 現在可以輸出定義的 JSON 了

OpenAI 在「Introducing Structured Outputs in the API」這邊提到目前的 JSON mode 不能保證 schema 的正確性：

While JSON mode improves model reliability for generating valid JSON outputs, it does not guarantee that the model’s response will conform to a particular schema.

而現在新的 model 可以了：

Today we’re introducing Structured Outputs in the API, a new feature designed to ensure model-generated outputs will exactly match JSON Schemas provided by developers.

新的 model 代碼是 gpt-4o-2024-08-06 這組，而且又降價了：

By switching to the new gpt-4o-2024-08-06, developers save 50% on inputs ($2.50/1M input tokens) and 33% on outputs ($10.00/1M output tokens) compared to gpt-4o-2024-05-13.

這個功能可以解掉不少 workaround...

合併 GitHub Actions 的 IP address

在 GitHub 官方文件「About GitHub's IP addresses」中，是有提到 https://api.github.com/meta 這組 API endpoint，可以取得當下的 GitHub Actions 所使用的連外 IP address，不過如果你實際掃下來後會發現量相當大，以現在的情況來說，IPv4 address 有 3708 筆，IPv6 address 則有 801 筆：

$ cat github-actions-ipv4.txt | wc
   3708    3708   58233
$ cat github-actions-ipv6.txt | wc
    801     801   17522

實際去看的時候會看到一些吐血的，像是這包 /31 的：

13.105.49.0/31
13.105.49.2/31
13.105.49.4/31
13.105.49.6/31
13.105.49.8/31
13.105.49.10/31
13.105.49.12/31
13.105.49.14/31
13.105.49.16/31

這包還真的就整整 128 筆，你就不能輸出個 13.105.49.0/24 嗎...

用 ChatGPT 問了要怎麼解決，被提示有 netmask 這個工具可以用，不需要另外自己編譯，可以直接用 apt 裝起來然後倒進去讓他跑就好，整包搭配 jq 與 HTTPie 處理掉 (換 curl 基本上也沒問題)：

netmask --cidr -- $(http https://api.github.com/meta | jq -r '.actions[]')

Update：看到資安的朋友按讚突然想到，這邊用了 $() 把資料丟到 command line 包裝，可能會有安全上的顧慮，請自己斟酌...

不過整包 (IPv4 + IPv6) 還是有 3187 行，但總是有個方法可以整理起來用，不用自己刻一堆程式處理...

用 jc 將常見的 CLI 指令輸出轉成 JSON 或是 YAML

看到「kellyjonbrazil/jc」這個專案，展試一下就可以理解用途了：(最後接 jq 只是為了 pretty print)

$ dig www.google.com | jc --dig | jq
[
  {
    "id": 57567,
    "opcode": "QUERY",
    "status": "NOERROR",
    "flags": [
      "qr",
      "rd",
      "ra"
    ],
    "query_num": 1,
    "answer_num": 1,
    "authority_num": 0,
    "additional_num": 1,
    "opt_pseudosection": {
      "edns": {
        "version": 0,
        "flags": [],
        "udp": 1232
      },
      "cookie": "37fe52c319e24fbbeadce09b6579665ea173fcd360d0a298"
    },
    "question": {
      "name": "www.google.com.",
      "class": "IN",
      "type": "A"
    },
    "answer": [
      {
        "name": "www.google.com.",
        "class": "IN",
        "type": "A",
        "ttl": 249,
        "data": "142.251.42.228"
      }
    ],
    "query_time": 0,
    "server": "168.95.192.1#53(168.95.192.1) (UDP)",
    "when": "Wed Dec 13 16:07:58 CST 2023",
    "rcvd": 87,
    "when_epoch": 1702454878,
    "when_epoch_utc": null
  }
]

覺得可以開始用的原因是發現從 Ubuntu 22.04 開始，在官方的 APT repository 有把 jc 包進去了，裝起來會簡單不少。

雖然 22.04 裡面包的版本是 1.17.3 (現在是 1.23.6)，但這個版本已經支援不少格式了。

之後在 shell script 裡面自己 grep + sed 組到起笑的時候，可以考慮加掛 jc + jq 的組合技來解決，不過缺點就是要額外裝...

用 Fly.io 跑 RSS-Bridge，再把現有的 twitter2facebook 與 twitter2plurk 改寫

Twitter 把我本來 read-only 的兩個應用程式停用掉了，加上這陣子的新聞，就改用其他方式來處理。

用的是先前在「用 RSS-Bridge 接服務」提到的 RSS-Bridge，可以將 Twitter 的資料轉成 JSON Feed。

其中 RSS-Bridge 是 PHP 寫的，剛好就拿先前在「在 Fly.io 上面跑 PHP」這邊提到的方法丟上 Fly.io，不需要自己架主機跑了。

然後把 twitter2facebook 與 twitter2plurk 這兩個專案裡面本來抓 Twitter API 的程式碼改成抓 JSON Feed。

先這樣子弄，之後再看看要不要搬...

SQL:2023 的新玩意

Hacker News 上看到「SQL: 2023 is finished: Here is what's new (eisentraut.org)」這篇題到了 SQL:2023 標準的新東西，對應的原文在「SQL:2023 is finished: Here is what's new」這邊。

「UNIQUE null treatment (F292)」讓你可以決定 NULL 到底要不要算 unique，剛好跟之前寫過的「PostgreSQL 15 將可以對透過 UNIQUE 限制 NULL 的唯一性了」要做的事情一樣。

「ORDER BY in grouped table (F868)」則是針對沒有出現在 SELECT 的欄位頁可以 ORDER BY，看了一下說明，主要是在 JOIN 的時候限制住了。很明顯的 workaround 是多加上這個欄位，但就代表會增加傳回的資料量。

「GREATEST and LEAST (T054)」這個因為 MIN() 與 MAX() 已經被 aggregate function 用掉了，所以只好另外取名。

「String padding functions (T055)」與「Multi-character TRIM functions (T056)」是熟悉的語法，各家都有對應的 function 可以做，但這次就放進標準化。

「Optional string types maximum length (T081)」是 VARCHAR 可以不用指定大小了，實務上應該是還好？

「Enhanced cycle mark values (T133)」這編提到的 recursive 真的是每次用每次忘，然後 cycle 這個功能就沒看懂了...

「ANY_VALUE (T626)」看起來可以隨機取出資料，搭配 GROUP BY '' 就不用拿 ORDER BY RAND() 這種髒髒的東西出來了？

「Non-decimal integer literals (T661)」與「Underscores in numeric literals (T662)」都是讓數字更好讀以及操作。

後面講了很多 JSON 功能，看起來是 SQL:2016 有先納入一些，但 SQL:2023 補的更完整了。

然後有 Graph 相關的標準也被定義進 SQL:2023，原文介紹的也不是很多，看起來是要跨足過來？

用 Perl 把 log 丟上 Slack

因為想在 Raspberry Pi 上面把一些 log 丟上 Slack，本來看到「Stream Any Log File to Slack Using curl」這篇，但發現裡面在把字串包進 JSON object 的方法太髒 (直接把 " 換成 ')，另外一方面是 Slack 已經在宣導不要用舊版的 Incoming Webhooks，所以決定用其他方式來處理。

選擇 Perl 主要是因為有一陣子沒有用 Perl 寫東西了，倒不是什麼特別的原因 (如果考慮到 Raspberry Pi 上資源有限的話，應該用 C 或是 Rust 或是 Go，但我的 Raspberry Pi 還沒忙到這種程度...)，所以決定用 Perl 來實做這個程式，把 log 檔案丟上 Slack：

這邊有些比較不太常見的選擇：

  • 不用 File::Tail 而反而是用 pipe 的方式取得 tail -F 的輸出，是因為 File::Tail 非常舊了 (2015)，實做上沒有用到 inotify 類的界面監控檔案的變化，反而是系統的 tail 有做。
  • 用 JSON::PP (pure perl 版本) 而不是 JSON 是因為 JSON::PP 在 Perl 5.14+ 後內建了，我沒有太在意效能，這也是上面放 use v5.14 的原因。
  • 這邊的 API 呼叫還是選擇了 WWW::Mechanize 是因為沒有內建的套件可以處理 HTTPS 連線 (可以參考 Perl core modules 這邊)，既然要另外安裝，就裝個支援度比較完整的 libwww-mechanize-perl 來用。

然後查了一下 // 的用法在 Perl 5.10+ 就支援了，好早...

OxideDB：另外一套用 PostgreSQL 為底的 MongoDB 相容層

看到 OxideDB 這個專案：

OxideDB is a translation layer that works as a MongoDB database server while using PostgreSQL's JSON capabilities as the underlying data store.

跟之前提到的 MangoDB 有些淵源 (參考「MangoDB：拿 PostgreSQL 當作後端的 MongoDB 相容層」)，順便提一下 MangoDB 後來被要求改名為 FerretDB：「MangoDB 改名為 FerretDB (雪貂)」。

主要的差異在於 OxideDB 只以 PostgreSQL 為底層，另外是用 Rust 寫的：

The project was heavily inspired by FerretDB and is on its early days. The main difference is that there is no intention to support any database other than PostgreSQL (FerretDB is also supporting Tigris) and it's written in Rust, as opposed to Go.

看起來大家都拿 PostgreSQL 在搞事，但這個專案裡面好像沒搜到 GIN 這個關鍵字，不知道是不是連 index 都沒下...

jless：檢視 JSON 的工具

前幾天在「Show HN: Jless, a command-line JSON viewer (pauljuliusmartinez.github.io)」這邊看到用 Rust 寫的 jless 這個工具，官網有個動圖可以參考：

這樣方便不少，就不需要自己在對半天...

另外也剛好拿來練手，把 Rust 寫的套件包成 Ubuntu PPA：「PPA for jless」。

主要是 cargo vendor 這個指令可以把相依套件都抓下來放到 vendor/ 下面，然後設定 .cargo/config.toml 後就可以在本地端處理了，這對於 build farm 限制 internet 連線的情況會好用很多...

curl 的 command line 工具也要支援 JSON 格式了

Daniel Stenberg 在 curl 的 mailing list 上宣佈要支援 JSON 格式：「JSON support」，用法在「JSON awareness in the curl tool」在這邊可以看到，另外在 Hacker News 上的討論「The time might come when we add some JSON specific command line options (curl.se)」也可以翻翻。

討論裡面馬上有提到 HTTPie，這個套件基本上也算是標配了 (而且在各大 distribution 的 package 都有內建，直接裝就可以了)，可以看到主要是處理 POST 輸入時的 JSON 部份 (在 Content-Type: application/json 的情境下)，HTTP response 輸出的部份一般都還是用 jq 處理。

不過 curl 自己又定義了一套指定 JSON 內容的方式...