XJDF API Rehberi
NowToPrint XJDF REST API v1 icin private-beta readiness endpoint, validation ve mesaj siniri referansi.
XJDF API Rehberi
NowToPrint XJDF yuzeyi, private-beta ve dark-launch kullanimi icin standart referansli bir readiness katmanidir. Bu katmanda XJDF 2.2, PrintTalk 2.2 ve harici mesajlasma icin XJMF kullanilir; bu sayfa CIP4 sertifikasyonu, yasal uygunluk veya external GA iddiasi degildir.
Kanonik sinir
Platform icinde kanonik cekirdek XJDF 2.2 + XJMF + PrintTalk 2.2'dir. Legacy JDF/JMF sadece
harici adapter katmaninda yasatilir.
Generated reference
Render edilen endpoint dokumani icin XJDF & PrintTalk API Reference
sayfasini kullanin. Kanonik machine-readable contract ise
/docs/api/xjdf-openapi.yaml adresindedir.
Temel endpoint'ler
| Endpoint | Amac |
|---|---|
GET /api/v1/xjdf | Discovery ve yuzey bilgisi |
GET /api/v1/xjdf/openapi | OpenAPI 3.1 spesifikasyonu |
GET /api/v1/xjdf/capabilities | Desteklenen urun, medya ve finishing yetenekleri |
POST /api/v1/xjdf/validate | XJDF dokuman dogrulama |
Master Data-backed internal bridge
Master Data-backed XJDF bridge route'lari public contract degildir. Kodda route'lar var olabilir, ancak /api/v1/xjdf/media-catalog, /api/v1/xjdf/master-data-export ve /api/v1/xjdf/devices internal-only kabul edilir; public discovery ve public OpenAPI tarafinda yayinlanmaz.
Internal bridge su ailelerde kanonik modelden ResourceSet uretir:
paperveyamediamachineveyadeviceinklaminationvarnishplateadhesiveelectricitylabor
External kullanicilar bu route'lara dogrudan baglanmamalidir. Master-data semantigi icin ana referans: XJDF Master Data Modeli
Validation
POST /api/v1/xjdf/validate endpoint'i dokumani schema ve temel semantik kurallara gore kontrol eder.
curl -X POST https://api.nowtoprint.com/api/v1/xjdf/validate \
-H "Content-Type: application/json" \
-d '{
"@Version": "2.2",
"ProductList": {
"Product": { "@ProductType": "BusinessCard" }
}
}'
Validation su sorulari cevaplar:
- schema gecerli mi?
- beklenen vocabulary kullaniliyor mu?
- desteklenmeyen alan veya kategori var mi?
XJMF ve webhook siniri
XJMF webhook'lari yalnizca harici vocabulary kabul eder. Ic workflow stage'leri dis Status alani icine yazilmaz.
Beklenen prensip:
- external XJMF status = partnerlar arasi mesajlasma dili
- internal workflow stage = platform ici event dili
Bu ayrim birlikte calisabilirlik icin zorunludur.
Inbound XJMF callback icin /api/v1/webhooks/xjmf kullanilir. Bu route
X-XJMF-Signature, X-XJMF-Sender ve X-XJMF-Timestamp header'larini ister;
sender server-side XJMF_SENDER_SECRETS registry'sinde kayitli olmali ve
timestamp 5 dakikalik replay window icinde kalmalidir.
Guvenlik ve operasyon
- API erisimi API key veya uygun entegrasyonlarda mTLS ile korunur
- webhook ve signal alanlarinda signature dogrulamasi zorunludur
- unsupported veya dogrulanamayan source/compatibility durumlari confidence dusurur
- manual review gereken durumlar kesin quote gibi sunulmaz
Sik hata kodlari
| HTTP | Kod | Aciklama |
|---|---|---|
400 | VALIDATION_ERROR | Gecersiz XJDF yapisi veya semantik sorun |
400 | INVALID_CATEGORY | Gecersiz master-data kategorisi |
401 | MISSING_API_KEY | API key saglanmadi |
401 | INVALID_API_KEY | Gecersiz API key |
403 | INSUFFICIENT_SCOPE | Yetersiz izin kapsami |
429 | RATE_LIMIT_EXCEEDED | Hiz limiti asildi |
Ilgili konular
هل كانت هذه المقالة مفيدة؟
مقالات ذات صلة
Last updated on