@cosense/std@0.30/restの破壊的変更案

scrapbox-userscript-stdのScrapbox REST API wrapperのinterfaceに破壊的変更を加えるつもり

その内容と意図を記す

どこかにもう書いた気がするけどまあいいかtakker.icon

変更点

引数は変更なし

戻り値

変更前：各APIの返り値を適当なJSONやテキストに整形したものと、独自のError objectとのResult<T, E>のPromiseを返す

Typed Response：NativeのResponse objectを型安全にしたもの

Response.json()に型をつけたり、Response.okによってjson()の型を変えたりできる

HonoのClientResponseが採用している方法

fetchのエラーをthrowせずにResultで返す

内部でResult<Response, TypeError>を返すneverThrowfetchを使う

別途外部からもfetchを入れられるようにする

その際任意のエラーをResultで返せる用にする

HTTPErrorはResponse.ok===falseのとき、text()やjson()経由で変えさせる

検討中

toRequestも消す？

いや、代替コードをuser側で書くのは面倒だ

getPage.toRequestではなく、getPageRequestという名前にぞれぞれ変えよう

従来のはtoRequestの名前がminifyされないので若干不利

roadmap

0.29.xにて、/clientに実装する

名前はhonoを参考にした

/restは@deprecatedにする

2024-12-21 22:35:57 いや、/rest-apiのほうがいいかも

/clientでは、web browserとserverとの対比だと誤解しかねない

0.30にて/restを削除する

理由

responseを直に扱いたい

status code, http headerの取り出し

Response.prototype.bodyから逐次的に読み出す

など

以前は📝Requestの組み立てとResponseの解析を分離しようとしていたが、Honoが使っているこの設計のほうがシンプルだしランタイムコードも減るので、こちらにする

code:ts

export interface TargetedResponse<

Status　extends number = StatusCode,

Scheme extends Record<StatusCode, JSONValue | Blob　| ReadableStream>

extends globalThis.Response {

ok: Status extends SuccessStatusCode ? true : Status extends Exclude<StatusCode, SuccessStatusCode> ? false : boolean;

status: Status;

text(): Promise<SchemeStatus extends string ? SchemeStatus : SchemeStatus extends JSONValue ? string : never>;

json(): Promise<SchemeStatus extends JSONValue ? SchemeStatus : never>;

body: SchemeSuccessStatus extends ReadableStream ? SchemeSuccessStatus : ReadableStream　| null;

}