Mastodon API を使ってみる


Mastodon API の使い方などの説明です (2018/8/15 新規作成)。

Mastodon / API / REST / Streaming / WebSocket / Web Push / 認証 / ID / ID範囲 / 文字数 / 制限 / ActivityPub / / 戻る / トップページ


Mastodon

Mastodon は脱中央集権型のミニブログで、 だれでも自由に運用できるTwitterに似たサービスです。
 
Mastodon APIは、タイムラインを参照したりトゥート(Twitterのツイート)したりする機能が 用意されています。 公式クライアント(インスタンスのWebページ)でも使われているため、 クライアントやBOTを作るのに必要な機能は揃っています。

Mastodon APIの基本

Mastodon APIは基本的にOAuth2.0で認証をするREST APIで、 レスポンスはJSON形式です。 ドキュメントは こちら (2018/10以前はGitHub) で提供されています。
 
認証周りから手を付けていくと、 実際に使うまでに長い説明が必要になってしまうので、 まずは認証を必要としない 指定IDのトゥートの情報を得るAPI から呼んでみましょう。
    https://インスタンス名/api/v1/statuses/トゥートID
具体例として https://mastodon.social/api/v1/statuses/99730307203414093 をブラウザで開くと、レスポンスがJSONで表示されると思います。
 
次に認証ありを試しましょう。 OAuthではインスタンス(サーバー)にアプリ情報を登録して クライアントキー・クライアントシークレットを準備し、 この値とAPIを駆使して利用者に アプリからのアクセスを認可してもらいます。 その証として「アクセストークン」が得られるので、 アクセストークン情報を付与してAPIを呼び出す流れとなります。 これも実際に使うまでに長い説明が必要になってしまうので、 アプリ情報を登録するアカウント自身だけであればWeb上の操作だけで アクセストークンを直接得られますので、その方法からやってみましょう。
 
まず、適当なMastodonインスタンス(サーバー)で実験に使うアカウントを用意し、 「ユーザー設定」画面に入ります。 サイドバーから「開発」→「アプリ」を選び「新規アプリ」ボタンを押します。 「アプリの名前」に "API Test" など名前を入力したら他の情報はそのままで、 送信ボタンを押してアプリ登録をします。 生成されたアプリ名を選ぶと、アクセストークン等の情報が表示されます。
 
あとは、APIにアクセスする際に、ヘッダー名 "Authorization" に "Bearer アクセストークン" を渡すだけです。 ここでは、ホームタイムラインを取得する JavaScriptの例を載せておきます。
	var xmlHttpRequest=new XMLHttpRequest();
	xmlHttpRequest.addEventListener("load",function(event) {
		// xmlHttpRequest.responseにレスポンスが入っています
	},false);
	xmlHttpRequest.responseType="json";
	xmlHttpRequest.open("GET","https://インスタンス名/api/v1/timelines/home");
	xmlHttpRequest.setRequestHeader("Authorization","Bearer アクセストークン");
	xmlHttpRequest.send();
なお、デフォルトで Access-Control-Allow-Origin ヘッダーが送出されるので、 クロスドメインでアクセスできます (インスタンスの管理者が設定を変更していない限り)。

REST API

後はこの応用で色々なAPIを呼び出せます。 ドキュメント から欲しいAPIを探せば、 必要なURLとパラメータが分かります。 レスポンスの詳細はドキュメントのEntitiesに書いてあり、 Entities単体か配列が返ってきます。
 
APIは基本的にドキュメントから探せますが、 新しいAPIはまだ反映されていないことがまれにあるため、念のため リリースノート も参照した方が良いです。 ドキュメント化されてないAPIとして、 インスタンスの統計情報や接続先インスタンスを取得する GET /api/v1/instance/peers, GET /api/v1/instance/activity (Mastodon2.1.2以降) があるようです。
 
トゥートも普通にPOSTでできます。 自動でトゥートする時はマナーとしてローカルタイムラインに載らないように 非収載 (visibility=unlisted) 指定をしましょう。
	var xmlHttpRequest=new XMLHttpRequest();
	xmlHttpRequest.addEventListener("load",function(event) {
		// xmlHttpRequest.responseにレスポンスが入っています
	},false);
	xmlHttpRequest.responseType="json";
	xmlHttpRequest.open("POST","https://mstdn.jp/api/v1/statuses?access_token=アクセストークン");
	xmlHttpRequest.setRequestHeader("Content-Type","application/x-www-form-urlencoded; charset=UTF-8");
	xmlHttpRequest.send("status="+encodeURIComponent("テスト")+"&visibility=unlisted");
	// file:///以下から試すと422エラーになるので注意
ドキュメントに明記されていないため いつか使えなくなってしまうかも知れませんが、 この例のようにどのAPIでも、 アクセストークンはヘッダーではなく クエリーに "access_token=アクセストークン" を渡すことでも使えるようです。
 
タイムラインのようにレスポンスに続きがある時は HTTPのレスポンスヘッダーの "Link" にページング先のアドレス が渡されます。 引数でページ数等を指定するのではなく、 Linkヘッダーのnext, prevで示されたURLを開くことで次・前ページの情報を得ます (それらしい引数が含まれていても、 内部IDで将来的に変更されうるので直接扱ってはいけません)。
	xmlHttpRequest.addEventListener("load",function(event) {
		// xmlHttpRequest.responseにレスポンスが入っています
		
		// xmlHttpRequest.getResponseHeader("Link")にページング情報
		var links=xmlHttpRequest.getResponseHeader("Link").split(/, /);
		var pagination={};
		for (var i=0;i<=links.length-1;i++)
		{
			var parsed=links[i].match(/<([^>]+)>; rel="([^"]+)"/);
			pagination[parsed[2]]=parsed[1];
		}
		// 次ページを開くなら pagination.next
		// 前ページを開くなら pagination.prev
	},false);
任意個の引数を渡せるAPIでは、 https://mstdn.jp/api/v1/accounts/relationships?id[]=1231&id[]=42645&id[]=429164&id[]=72843&id[]=63076 のように 引数名に[]をつけて複数指定することで実現します。

Streaming API

REST APIはこちらからAPIを呼び出すため、 トゥートを受信した瞬間に処理をすることが実現できません。 そこで、Streaming APIが用意されています。
 
Streaming API は呼び出し方法はREST APIと同じですが、 接続を持続して返すべき情報が出来た時にその分だけレスポンスを返すことで、 リアルタイムな情報をやりとりする仕組みです。 Mastodonでは流れるタイムラインを実現するために Streaming APIが利用されています。
	var xmlHttpRequest=new XMLHttpRequest();
	var lastResponse="";
	var data="";
	xmlHttpRequest.addEventListener("progress",function(event) {
		// chunk=今回受信した断片
		var chunk=xmlHttpRequest.response.substring(lastResponse.length);
		lastResponse=xmlHttpRequest.response;
		
		// data=まだ処理してない断片 (改行まで受信してるとは限らない)
		data=data+chunk;
		
		// 空行をスキップ
		data=data.replace(/^\n/gm,"");
		
		// タイムアウトで切断されないようにするためのダミーデータをスキップ
		data=data.replace(/^:(.*)\n/gm,"");
		
		var content;
		do {
			content=data.match(/^event: (.*)\ndata: (.*)\n([\s\S]*)$/);
			if (content!=null)
			{
				var event=content[1];
				var payload=(content[2]!="undefined" ? JSON.parse(content[2]) : null);
				
				// event(イベント名), payload(データ内容)で処理をする
				
				data=content[3];
			}
		} while (content!=null);
	},false);
	xmlHttpRequest.open("GET","https://mstdn.jp/api/v1/streaming/public/local");
	xmlHttpRequest.send(null);
データは "event: イベント名↵data: データ内容↵" の形でリアルタイムに流れてきます。データ内容はJSON型です。
 
Streaming APIのデータ
イベント名 イベント内容 データ内容
update 新しいトゥート Status
notification 新しい通知 Notification
delete トゥートの削除 削除されたトゥートのID
filters_changed 設定のフィルターの更新 (Mastodon2.4.3以降) なし (undefinedの文字)
 
しばらくデータを流さないとブラウザやサーバーが タイムアウトで切断してしまいます。 タイムアウトを防ぐために空行や:で始まるダミーデータが流れてくるため、 それらは読み捨てます。
 
なお、この例では認証不要のローカルタイムラインを受信していますが、 ホームタイムラインなどの認証が必要な時はREST API同様に "Authorization: Bearer アクセストークン" ヘッダーを設定するか、 クエリーに "access_token=アクセストークン" を追加します。

Streaming API (WebSocket版)

ドキュメント化されていませんが、Streaming APIにはWebSocket版があります。 さきほど説明したHTTP接続を持続させる方法はLong pollingと呼ばれ、 既存の技術の応用なので導入しやすい一方、 効率面などで最適とは言えません。 WebSocketは双方向の逐次通信を実現するために作られた 比較的新しい技術なため、利用可能な環境なら WebSocket版をお勧めします。 Internet Explorer以外のモダンブラウザならWebSocketはサポートされていますし、 公式Web UIもこちらを使っているようです。
 
WebSocketはhttpsではないプロトコルなので、 インスタンスに対して /api/v1/instance を呼び出し、 返ってきた値の urls.streaming_api をWebSocketのアドレスのベースに します (通常は wss://インスタンス名 になっています)。 このベースに /api/v1/streaming を足したアドレスが WebSocket版Streaming APIになります。 引数streamに種類を指定します (Long polling版とは指定方法が違う点に注意が必要です)。
 
Long polling版にも ドキュメントに書かれていないAPI があるので、 ここにまとめておきます。
 
Streaming API
WebSocket版 Long polling版 内容
/api/v1/streaming/?stream=user GET /api/v1/streaming/user 自分のホームタイムライン+通知
/api/v1/streaming/?stream=user:notification GET /api/v1/streaming/user/notification 自分へ通知
/api/v1/streaming/?stream=public GET /api/v1/streaming/public 連合タイムライン (認証不要)
/api/v1/streaming/?stream=public:local GET /api/v1/streaming/public/local ローカルタイムライン (認証不要)
/api/v1/streaming/?stream=public:media GET /api/v1/streaming/public?only_media=true 連合タイムラインのメディアのみ表示 (認証不要)
/api/v1/streaming/?stream=public:local:media GET /api/v1/streaming/public/local?only_media=true ローカルタイムラインのメディアのみ表示 (認証不要)
/api/v1/streaming/?stream=direct GET /api/v1/streaming/direct 自分のダイレクトメッセージ
/api/v1/streaming/?stream=hashtag GET /api/v1/streaming/hashtag 連合タイムラインのクエリーtag(#は含めない)で指定したハッシュタグのトゥート (認証不要)
/api/v1/streaming/?stream=hashtag:local GET /api/v1/streaming/hashtag/local ローカルタイムラインのクエリーtag(#は含めない)で指定したハッシュタグのトゥート (認証不要)
/api/v1/streaming/?stream=list GET /api/v1/streaming/list クエリーlistで指定した自分のリストのトゥート
GET /api/v1/streaming/health 動作確認用 ? (繋がるだけで何も流れない)
 
認証が必要なAPIでは クエリーに "access_token=アクセストークン" を追加します。
	// instanceInfoには /api/v1/instance のレスポンスを入れておく
	
	var socket=new WebSocket(instanceInfo.urls.streaming_api+"/api/v1/streaming/?stream=public:local");
	socket.addEventListener("message",function(event) {
		var data=JSON.parse(event.data);
		
		var event=data.event;
		var payload=(data.payload!="undefined" ? JSON.parse(data.payload) : null);
		
		// event, payloadで処理をする
	},false);
WebSocketに接続してしまえば後はデータが順次流れてきます。 Long polling版同様にevent, data情報が渡されますが形式が異なり、 { "event": イベント名, "payload": データ内容 } の形のJSON型で、 データ内容はもう一度JSON文字列化された形式で格納されていますので、 注意が必要です。

Web Push API

MastodonはWeb Push機能も実装されています。 公式Web UIでも使われていますが、Web Pushを使うと ユーザーがWebページを開いていなくても通知を受け取ることができます。 これを操作するAPIも公開されています。
 
インスタンスがアプリケーションサーバーの役割を担うため、 Webアプリ開発者は自前の通知元サーバーを用意する必要はありません (httpsなWebページからしか動作しないため、Webサーバーは必要ですが)。
 
Web Pushを使うにはService Worker, Notification APIを利用します。 まずブラウザのPushManagerに購読登録をして、 アプリケーションサーバーとブラウザがやりとりするのに必要な情報(エンドポイントや鍵)を受け取り、 MastodonインスタンスのREST API POST /api/v1/push/subscription に引き渡して登録をします。
	// Service Workerを登録しておく
	navigator.serviceWorker.register("serviceWorker.js");
	// Notification APIの利用許可を得ておく
	Notification.requestPermission(function(permission) { ... });
	
	function encodeBase64(buffer)
	{
		return window.btoa(
		    String.fromCharCode.apply(null,new Uint8Array(buffer)))
		    .replace(/\+/g,"-").replace(/\//g,"_").replace(/=+$/,"");
	}
	function decodeBase64(string)
	{
		return new Uint8Array([].map.call(
		    window.atob((string+"=".repeat((4-string.length%4)%4))
		    .replace(/\-/g,"+").replace(/_/g,"/")),
		    function(c) { return c.charCodeAt(0) }));
	}
	
	navigator.serviceWorker.ready.then(function(registration) {
		registration.pushManager.subscribe({
			userVisibleOnly: true,
			applicationServerKey: decodeBase64("VAPID公開鍵"),
		}).then(function(subscription) {
			var endpoint=subscription.endpoint;
			var publicKey=encodeBase64(subscription.getKey("p256dh"));
			var authSecret=encodeBase64(subscription.getKey("auth"));
			
			var xmlHttpRequest=new XMLHttpRequest();
			xmlHttpRequest.open("POST","https://インスタンス名/api/v1/push/subscription?access_token=アクセストークン");
			xmlHttpRequest.setRequestHeader("Content-Type","application/x-www-form-urlencoded; charset=UTF-8");
			xmlHttpRequest.send(
			    "subscription[endpoint]="+endpoint+
			    "&subscription[keys][p256dh]="+publicKey+
			    "&subscription[keys][auth]="+authSecret+
			    "&data[alerts][follow]=true&data[alerts][favourite]=true"+
			    "&data[alerts][reblog]=true&data[alerts][mention]=true");
		});
	});
ブラウザに購読登録をする際にVAPID公開鍵を渡す必要がありますが、 VAPID公開鍵を取得するAPIが現状ないため、 公式Web UIの通知設定画面のHTMLソースから手動で抽出しましょう。 applicationServerKeyの名前のmetaタグに記述されています。
 
登録に成功すると、後は通知が起こったときにService Workerのイベントが発生するので、ユーザーにその情報をNotification APIで知らせます。
	// serviceWorker.jsの中身
	self.addEventListener("push",function(event) {
		var data=event.data.json();
		
		// data.notification_typeには"favourite"など通知の種類
		return event.waitUntil(
			self.registration.showNotification(
				data.title,			// 通知内容の文章
				{
					icon: data.icon,
					body: data.body,		// 対象のトゥートなど
				}
			)
		);
	});

認証

Mastodon APIは基本的にOAuth2.0で認証をします。 特定のアカウントだけでAPIを呼ぶのであれば、 さきほどのようにWeb上の操作だけでアクセストークンを得られますが、 任意のアカウントに対してAPIアクセスを認可してもらうためには 手順が必要になります。 ここではその手順について説明します。
 
認証は最終的にアクセストークンが得られればAPIを呼ぶ権利が得られるため、 そこを目指します。 まずおさらいです。
  1. インスタンスにアプリ情報を登録してクライアントキー・クライアントシークレットを得る
  2. 「あなたのアカウントへのアクセスを要求しています。」画面を出して、ユーザーに承認してもらう
  3. 承認情報を元にアクセストークンを得る
このような流れとなります。
 
アプリ情報の登録
 
Mastodonはインスタンスごとに違うサーバーが使われているので、 ユーザーが新しいインスタンスを使っていたら 都度アプリ情報の登録が必要になります。
	var clientId,clientSecret;
	
	var xmlHttpRequest=new XMLHttpRequest();
	xmlHttpRequest.addEventListener("load",function(event) {
		clientId    =xmlHttpRequest.response.client_id;		// クライアントキー
		clientSecret=xmlHttpRequest.response.client_secret;	// クライアントシークレット
		
		// 次のステップへ
	},false);
	xmlHttpRequest.responseType="json";
	xmlHttpRequest.open("POST","https://インスタンス名/api/v1/apps");
	xmlHttpRequest.setRequestHeader("Content-Type","application/x-www-form-urlencoded; charset=UTF-8");
	xmlHttpRequest.send("client_name="+encodeURIComponent("アプリ名")+
	    "&redirect_uris=リダイレクト先"+
	    "&scopes="+encodeURIComponent(["read","write"].join(" ")));
	// file:///以下から試すと422エラーになるので注意
このようにアプリ名と、ユーザー承認後に飛ばすリダイレクト先、 認可してもらう権利を渡して/api/v1/appsを呼ぶと、 クライアントキー・クライアントシークレットが得られます。 当然ですがこのAPI自体は認証不要で呼べます。
 
引数redirect_urisにはユーザー承認後に飛ばすリダイレクト先のアドレスを指定します。 アプリがWeb形式ではない場合はリダイレクト先に 特殊な値 "urn:ietf:wg:oauth:2.0:oob" を指定することができます。 その場合はユーザーが承認した後にコードが表示されるので、ユーザーに 自分のアプリにそのコードをコピー&ペーストして貰う方法で承認情報を貰います。
 
引数scopesには ユーザーに許可してもらう操作 を空白区切りで書きます。
 
scopes
scope 許可される操作
read 読み取り系
write 書き込み系 (トゥート)
follow フォロー、ブロック
push Web Push (Mastodon2.4.0以降)
 
Mastodon2.4.3以降では、 "read:statuses" 指定でタイムラインやトゥートの読み取りのみにするなど、 より 限定的な指定 ができるようになりました。
 
インスタンスがMastodonの最新バージョンを使っているとは限らないため、 新しいAPIを使う際はインスタンスそのものの情報が得られる 認証不要の/api/v1/instanceを呼んでバージョンチェックをすると良いでしょう。 具体例として https://mstdn.jp/api/v1/instance をブラウザで見ると分かるように、versionにバージョン情報が入っています。
 
ユーザーの認可
 
OAuth認可には何通りか方法がありますが、ここでは最も一般的な Authorization Code Grantを使います。 認可用のWebページのURLは次の形になります。
    https://インスタンス名/oauth/authorize?client_id=クライアントキー&scope=許可される操作&response_type=code&redirect_uri=リダイレクト先
リダイレクト先と許可される操作は、 先ほど登録したアプリ情報の範囲内である必要があります。 このURLを開くと「あなたのアカウントへのアクセスを要求しています。」 画面になるのでユーザーに承認してもらうと、 リダイレクト先のアドレスに飛びます。 リダイレクト先ではアドレスにクエリーの形で承認情報がついているので、 その中のcodeを次に使います。
    リダイレクト先?code=code&scope=許可される操作
リダイレクト先を特殊指定 "urn:ietf:wg:oauth:2.0:oob" にした時は、 ユーザーにコピー&ペーストしてもらった値がcodeになります。
 
承認情報からアクセストークン
 
受け取ったcodeと、 関連情報をアプリから認可用APIの/oauth/tokenへ投げて、 アクセストークンを受け取ります。
	var accessToken;
	
	var xmlHttpRequest=new XMLHttpRequest();
	xmlHttpRequest.addEventListener("load",function(event) {
		accessToken=xmlHttpRequest.response.access_token;	// アクセストークン
	},false);
	xmlHttpRequest.responseType="json";
	xmlHttpRequest.open("POST","https://インスタンス名/oauth/token");
	xmlHttpRequest.setRequestHeader("Content-Type","application/x-www-form-urlencoded; charset=UTF-8");
	xmlHttpRequest.send("client_id="+clientId+"&client_secret="+clientSecret+
	    "&redirect_uri=リダイレクト先"+
	    "&grant_type=authorization_code"+
	    "&code="+code);
JSON形式で情報が返ってきますが、 その中にaccess_tokenの値としてアクセストークンが入っています。
 
本来OAuthのアクセストークンは一定時間で失効するため、 この返り値の中に含まれるrefresh_tokenを使って 時々新しいアクセストークンに更新するのですが、 Mastodonのデフォルト設定ではユーザーが失効させない限りは使い続けられます。

ID

トゥートIDやアカウントID等のIDは数値で表現されていますが、 API上では文字列型で扱われています。 IDは64bit整数なので、プログラミング言語によって桁あふれを起こすためです。 2010年頃にTwitterのIDが53bitを越えたために、 JavaScriptの数値型(64bit浮動小数で、仮数部の52bitを越える)で 扱えなくなるため、IDを文字列型に変えた経緯があります。 それを参考にあらかじめ対応したのだと思います。
 
トゥートIDはインスタンスをまたいで一意になるよう、 Snowflake的な考えで設計されています。 ちなみに、上位48bitがUNIX時間になっているので、 特定時間のトゥートIDの範囲を算出することができます (unixtime×216〜unixtime×216+65535)。
 
なお、Mastodon1.*時代はIDは数値型で、算出ルールも違っていました。 バージョンの古いインスタンスでも動作させるアプリを作る際は注意が必要です。 Mastodon2.0になった際のAPIの唯一の破壊的変更になります。

IDの範囲指定

タイムラインや通知では 引数 max_id, since_id で取得範囲を絞ることができますが、 取得されるデータは since_id<id<max_id の範囲になります (Twitterのsince_id<id≦max_id とは微妙に違いますのでご注意を)。
 
Mastodon2.6以降では、似た指定として min_id がありますが、 こちらも取得されるデータは min_id<id の範囲です。 引数 limit で取得件数を指定しますが(指定しなくてもデフォルト値で) 指定範囲内の件数が溢れているときに、 since_id指定なら新しい方から、min_id指定なら古い方から、 その件数が得られます。
 
古いトゥートIDを基準にした時、その直後のトゥートが欲しいならmin_id指定を、 それ以降の最新のトゥートが欲しいならsince_id指定と使い分けます。 なお、min_idはmax_idと同時に指定することはできないようです (min_id指定が優先されます)。

文字数

Mastodonでの文字数のカウントは、原則見た目の数になっているようです。
 
英語・日本語とも1文字カウント、 サロゲートペア(例:🐲(U+1F432 または U+D83D U+DC32))でも1文字カウント、 ゼロ幅接合子で作られた文字(例:👨‍👩‍👦‍👦(U+1F468 U+200D U+1F469 U+200D U+1F466 U+200D U+1F466))も1文字カウント、 絵文字シークエンス各種(例:1️⃣(U+0031 U+FE0F U+20E3), 👏🏽(U+1F44F U+1F3FD), 🇯🇵(U+1F1EF U+1F1F5))も1文字カウントです。 ただし、漢字の異体字(例:葛󠄁(U+845B U+E0101))は現状2文字カウント(普通の漢字+異体字セレクタ)になっているようです。
 
Mastodon1.5.0以降は URLは23文字カウント、 別インスタンスのユーザー名はドメイン部分を除外してカウント(例:@Mastodon@mastodon.socialは@Mastodonの9文字カウント)です。 23の数字は実装時のTwitterの短縮URLのt.coの文字数にあわせたようですが (Twitterのように短縮URLに置き換えはしてません)、 ハードコードされているので 今後数字が増えることはなさそうです。

制限

ドキュメント化はされていませんが、APIの呼び出し回数には制限があるようです。 レスポンスヘッダー x-ratelimit-* に制限情報が入っています。
    x-ratelimit-limit: 300
    x-ratelimit-remaining: 299
    x-ratelimit-reset: 2018-08-30T02:40:00.363679Z
x-ratelimit-limit が制限数、x-ratelimit-remaining が残り回数、 x-ratelimit-reset が残り回数が復活する時間です。 APIの種類に関わらず共通でカウントされます。 デフォルトでは (インスタンスの管理者が設定を変更していない限り) アクセストークンごとに5分間に300コール(認証不要なAPIは7500コール)のようで、 普通はまず気にしなくてもよい緩さになっています。

ActivityPubのAPI

Mastodonは複数のインスタンス間を連合させて動作しますが、 その実現のためにActivityPubプロトコル (Mastodon1.6以降の話、それ以前や下位互換用としてOStatus)。 やWebFinger仕様を使っています ActivityPubはW3Cで勧告されている標準仕様で、 ActivityPubに対応している他のSNSのアカウントもフォローできるのは そのおかげです。
 
ActivityPub/WebFingerを実現するためにAPIが整備されているため、 これを利用することができます。 ただし、クライアント開発者向けに提供されているのではない、 内部的に使っている機能を勝手に使うことになるので、 アドレスや仕様変更される可能性がないとは言えない点には気をつけましょう。 実装目的が違うため、形式等もREST APIと統一されてませんし、 余計な情報も含まれていますが、 認証不要で情報が拾えるため上手く使えば便利です。
    https://インスタンス名/users/アカウント名.json (アカウント情報)
    https://インスタンス名/users/アカウント名/following.json?page=1 (フォロー情報)
    https://インスタンス名/users/アカウント名/followers.json?page=1 (フォロワー情報)
    https://インスタンス名/users/アカウント名/outbox?page=true (タイムライン情報)
    https://インスタンス名/users/アカウント名/トゥートID.json (トゥート情報)
    https://インスタンス名/tags/ハッシュタグ(#は含まない).json (ハッシュタグ検索結果情報)
/users/アカウント名 はどれも /@アカウント名 としても同じです。 アドレスさえ知っていればログインせずに見られるページのURLに .jsonを付ければ大抵情報が取れます。

その他の機能

フィード
 
APIではありませんが、外部ツールと連携するのに便利なフィード情報があります。
    https://インスタンス名/users/アカウント名.atom
    https://インスタンス名/users/アカウント名.rss
    https://インスタンス名/@アカウント名.atom (users/アカウント名.atomと同じ)
    https://インスタンス名/@アカウント名.rss  (users/アカウント名.rssと同じ)
例として https://mastodon.social/users/Mastodon.atom をブラウザで開くと、 指定したアカウントのトゥート情報が取れるのがわかると思います。
 
REST APIの項で書いたように、アクセストークンをWebページから取得したら、 https://インスタンス名/api/v1/statuses?access_token=アクセストークン に "status=トゥート内容&visibility=unlisted" をPOSTするだけで トゥートもできますので、 この二つを使って、外部サービスとのトゥートの入出力は簡単に実現できます (アクセストークンは漏洩しないように注意)。
 
Webページへの埋め込み
 
Web UIでトゥートの「…」メニューから「埋め込み」を選ぶことで、 個別のトゥートをWebページに貼り付けることもできます。 https://インスタンス名/@アカウント名/トゥートID/embed でも直接表示できますが、適切なサイズにしてくれるので 埋め込みメニューから取得したコードを使った方が良いです。
 
公式のタイムライン等の埋め込みはまだないようです。
 
oEmbed
 
埋め込みコードをWebサービスに限らず生成する仕様であるoEmbedに、 Mastodonも対応してます。
    https://インスタンス名/api/oembed.json?url=埋め込みたいページのURL
埋め込みたいページのURLはトゥートなら https://インスタンス名/@アカウント名/トゥートID になります。
 
Card
 
URLが書かれているトゥートの詳細表示をすると、 画像や動画等が埋め込まれたり ()、 リンク先の詳細情報を表示することがあります ()。 これはリンク先のページの情報を元に展開するCardと呼ばれる機能です。
 
Mastodonではリンク先のページがoEmbedか、 Open Graph Protocol(OGP)情報を持っていると解析してくれるようです。
 
Intents
 
Mastodonはインスタンス(サーバー)が複数あるために シェアボタンやフォローボタンを実現するのに一工夫必要です。 そのために、特殊なプロトコルweb+mastodon:が用意されています。 Mastodon1.6.0以降でモダンブラウザであればWeb UIにログインしているときに (開いてから5分ぐらいすると) web+mastodon:の登録を促されると思います。 この登録をした後であれば、 以下のURLにアクセスした時にシェアやフォロー画面に遷移できます。
    web+mastodon://share?text=トゥート本文 (シェア)
    web+mastodon://follow?uri=インスタンス名@アカウント名 (フォロー)
公式Widgetはないので、自分でリンクしましょう。

戻る