Results matching “API スキーマ”

4Aモデル（AI Agent Application Architecture）

4Aモデル（AI Agent Application Architecture）は、LLMベースのAIエージェントアプリケーションを迅速かつ拡張性高く構築するためのリファレンスアーキテクチャです。以下の6つのレイヤーで構成され、エンタープライズ用途に対応可能なセキュリティ・柔軟性・観測性を備えています：


User Interface Layer
Gateway Layer
Orchestrator / Reasoning Layer
MCP Server / Tool Layer
Data / API Layer
Context / Memory Layer

JSON Schema

JSON Schema Validation: A Vocabulary for Structural Validation of JSON

キーワード

型Keyword用途Value型Schema Sample
すべて

 type 型定義 string or array

"type": "object"

"type": "string"

"type": "number"

"type": ["string", "number"]
enum 列挙定義 array

"enum": ["東京", "大阪", "名古屋"]
const 定数定義 すべて

"const": 5

"const": "日本"
title タイトル string "title": "sample api schema"
description 概要 string "description": "sample api schema"
default デフォルト すべて

"default" : "default value"
readOnly 読出しのみ boolean "readOnly": true
writeOnly 書込みのみ boolean "writeOnly": true
examples サンプル array "samples": ["abc", "def", "ghi"]
数字
number & integer


 multipleOf 倍数 number

"multipleOf": 5

"multipleOf": 2.5

maximum 最大値 <= number "maximum": 100
exclusiveMaximum 最大値 < number "exclusiveMaximum": 100
minimum 最小値 >= number "minimum": 100
exclusiveMinimum 最小値 > number "exclusiveMinimum": 100
String

 maxLength 最長 non-negative integer "maxLength": 64
minLength 最短 non-negative integer "minLength": 4
pattern 正規表現よる文字列定義 string "pattern": "[abc]+"
Array




 items 配列要素のスキーマ定義 JSON schema
or array of JSON schema		 "items": { "type": "integer" }
additionalItems 拡張要素のスキーマ定義 JSON schema "additionalItems": { "type": "string" }
maxItems 最大サイズ non-negative integer "maxItems": 10
minItems 最小サイズ non-negative integer "minItems": 10
uniqueItems 同じ値の要素が許可できるか boolean "uniqueItems": true
contains 必須要素タイプ JSON schema "contains": { "type": "integer" }
Object






 maxProperties 属性数最大値 non-negative integer "maxProperties": 5
minProperties 属性数最小値 non-negative integer "minProperties": 2
required 必須属性 array

"required": ["name", "email"]
properties 属性定義 object

"properties": {
"name": { "type": "string" },
"id": { "type": "number","minimum": 2 }
"enum": ["man", "woman", "others"]
}
patternProperties 正規表現よる属性定義 object

"patternProperties": {
"^class.*$": { "type": "string" },
"^grade.*$": { "type": "number" }
}
additionalProperties 拡張属性のスキーマ定義 JSON schema "additionalProperties": { "type": "string" }
dependencies 依存関係 object

"dependencies": {
"credit_card": {
"properties": "billing_address": { "type": "string" }
},
"required": ["billing_address"]
}
}
propertyNames 属性名 JSON schema "propertyNames": { "format": "email" }
条件キーワード

 if/then/else 条件判定よるスキーマ定義 JSON Schema

{
"if": { "properties": { "power": { "minimum": 9000 } } },
"then": { "required": [ "disbelief" ] },
"else": { "required": [ "confidence" ] }
}

{
"type": "integer",
"minimum": 1,
"maximum": 1000,
"if": { "minimum": 100 },
"then": { "multipleOf": 100 },
"else": {
"if": { "minimum": 10 },
"then": { "multipleOf": 10 }
}
}
allOf 複数条件 array

"allOf": [
{ "maximum": 3 },
{ "type": "integer" }
]
anyOf 任意条件 array

"anyOf": [
{ "maximum": 3 },
{ "type": "integer" }
]
oneOf うちの一つ array

"oneOf": [
{ "maximum": 3 },
{ "type": "integer" }
]
not でない JSON Schema "not": { "type": "string" }
Encoding contentEncoding エンコード(rfc2945) string "contentEncoding": "base64"
contentMediaType メデイア(rfc2046) string

"contentMediaType": "text/plain; charset=utf8"

"contentMediaType": "text/html"

"contentMediaType": "image/png"
再利用

definitions

$ref

 定義済みスキーマの再利用 object

{
"type": "array",
"items": { "$ref": "#/definitions/positiveInteger" },
"definitions": {
"positiveInteger": {
"type": "integer",
"exclusiveMinimum": 0
}
}
}

クレジットカードデータ利用に係るAPIガイドライン

「キャッシュレス・ビジョン」「クレジットカードデータ利用に係るAPIガイドライン」を策定しました

経済産業省は、クレジットカード会社のAPI※連携促進に向けた具体策等を検討する「クレジットカードデータ利用に係るAPI連携に関する検討会」を昨年3月に立ち上げました。

また、昨年11月からは、近年の支払い手段の多様化を踏まえて検討対象を拡大し、キャッシュレス推進のための課題と今後の方向性について議論を行い、
今般、「キャッシュレス・ビジョン」及び「クレジットカードデータ利用に係るAPIガイドライン」を策定しました。

※API（Application Programming Interface）とは、プログラムがその機能を他のプログラムから利用できるようにするためのインターフェイスのこと。
例えば、カード会社以外の者がカード会社のシステムの機能を利用できるようにするための、システム側の接続口を指す。

クレジットカードデータ利用に係るガイドライン(PDF形式：1,267KB)を読みました。

ちょうど先週サービス化(API化)の本質はソフトウェア産業化を書いていたから、
このガイドラインの発表が自分の見解を証明するようなものです。
なお、十数年前から社内API開発ガイドラインを担当した人間としては大変興味深い資料ですね。

Micro API Design Pattern

面白い記事を見つけました。
What is The Micro API Design Pattern?
The Micro API Design Pattern
PHP Micro API Engine

要注意のは、ここが言ってるのは、Micro APIデザインパターンのことで、スキーマのことではありません。
micro-api.orgがJSON-LDベースで、hypermediaリンクを促進するために作ったスキーマがありますが、名前が同じですからちょっと混乱しやすい。

There is No U in CRUD

There is No U in CRUD

API設計時にCRUD（Create、Read、Update、Delete）を捨てて、ドメイン駆動設計しましょうというアマゾンの方の話です。

POST /account - open a new account. PUT /account//close - close an existing account. PUT /account//debit - remove money from an account. PUT /account//credit - add money to an account. GET /account/ - load single account by its account id GET /account//transactions - list transaction history for an account. GET /accounts/query/customerId/ - list accounts for the given customer id.

OpenAPI 3.0プレビュー

OpenAPI 3.0プレビュー

新しいOpenAPI 3.0仕様には、以下のような改善点がある。

図にあるように、仕様の全体構造がリファクタリングされて、再利用しやすくなる。
JSONスキーマに、oneOf、anyOf、notのサポートを追加。
パラメータにスキーマが利用可能に。
Cookieパラメータが入り、dataFormパラメータがなくなる。
Bodyパラメータに独自のエンティティを追加。
Contentタイプがネゴシエーション可能に。
複数ホストに対応。
セキュリティ定義の簡素化、強化。
WebHookがコールバックメカニズムで記述できなくなる。