Die Unterscheidung zwischen Karten-SDK und Karten-API ist eine Frage der Zuständigkeit, keine Produktwahl. Ein Karten-SDK bündelt wiederverwendbare clientseitige Komponenten, den Lebenszyklus und die Browserauthentifizierung. Eine Karten-API stellt Geodaten über programmatische Anfragen bereit. Eine Kartenplattform bietet beide Ebenen sowie Authentifizierung, Daten, Analysen, Nutzungskontrollen und Support. Die meisten produktiven Kartenprodukte verwenden mehr als eine Ebene.
Die folgenden Abschnitte trennen die drei Ebenen, weisen die Zuständigkeiten zu und dokumentieren Kaleidr anhand der aktuellen öffentlichen Entwicklerseiten. Weiterführende Informationen finden Sie unter Was ist ein KI-Karten-SDK?, No-Code Map Builder vs. Map API, Map API-Authentifizierung und Was ist eine Location Intelligence API?. Teams, die bereits eine Implementierungsform gewählt haben, können direkt zur Kaleidr-Kartierung springen; Teams, die die Ebenen noch benennen, sollten mit der Vergleichstabelle beginnen.
Vergleichsgrundlagen
- Benennen Sie den Auftrag, dann die Ebene: Ein SDK ist für das Clientverhalten zuständig; eine API für den Servicevertrag; eine Plattform für gemeinsame Operationen.
- Behandeln Sie die Bedingungen nicht als konkurrierend: Produktionsprodukte verwenden routinemäßig ein SDK, eine API und Plattformsteuerungen gemeinsam.
- Hostregeln autoritativ halten: Identität, Mandantenberechtigungen, private Datensätze und Transaktionen verbleiben in der Hostanwendung.
- Anmeldeinformationen nach Laufzeit aufteilen: Browsersichere, veröffentlichte Schlüssel und Serverschlüssel stellen unterschiedliche Bedrohungsmodelle dar.
- Bestätigen Sie den aktuellen Vertrag: Die Kaleidr-Entwicklerdokumentation beschreibt derzeit
kaleidr.jsProdukte, Plattform-API-Familien und Schlüsselbereiche; Marketingtexte sind nicht der API-Vertrag.
Worin unterscheiden sich Karten-SDK, Karten-API und eine Kartenplattform?
Die sinnvolle Unterscheidung liegt in der jeweiligen Funktion der einzelnen Ebenen. Ein Karten-SDK ist im Client integriert und kapselt wiederverwendbare Funktionen: Komponenten, den Lebenszyklus der Karteneinbindung, Karteneinbindung, Ereignisse und browsersichere Sitzungsverwaltung. Eine Karten-API ist ein programmatischer Vertrag für räumliche Funktionen wie Suche, Routing, Datenabruf, Inferenz, Kacheldarstellung oder Design. Eine Kartenplattform ist das übergeordnete System, das beides sowie Authentifizierung, Datendienste, Tools, Analysen, Veröffentlichung, Kontingente und Support umfassen kann. AWS definiert ein SDK derzeit als eine Reihe plattformspezifischer Entwicklungswerkzeuge wie Bibliotheken, während eine API ein Mechanismus ist, der es zwei Softwarekomponenten ermöglicht, über vordefinierte Protokolle zu kommunizieren. AWS weist darauf hin, dass ein SDK neben anderen Ressourcen auch APIs enthalten kann (What's the Difference Between SDK and API?).
Anbieterplattformen verwenden in ihrer öffentlichen Dokumentation dieselbe Struktur. Google beschreibt die Google Maps Platform aktuell als eine Sammlung von APIs und SDKs, mit denen Entwickler Karten in Apps und Seiten einbetten oder Daten von Google Maps abrufen können (Google Maps Platform FAQ). Derselbe Anbieter veröffentlicht diese Funktionen derzeit als getrennte API-Familien nach Plattform (Google Maps Platform APIs nach Plattform). Mapbox beschreibt aktuell eine modulare Standortplattform, bestehend aus APIs, SDKs und Tools, die Entwickler für individuelle Standortfunktionen kombinieren können (Erste Schritte). Diese Seiten sind maßgeblich für die Benennung der jeweiligen Plattform durch die Anbieter. Sie belegen jedoch nicht, dass jedes Produkt für einen einzelnen Geocode eine vollständige Plattform erwerben muss.
| Frage | Karten-SDK | Karten-API | Kartenplattform |
|---|---|---|---|
| Hauptaufgabe | Wiederverwendbares clientseitiges Verhalten hinzufügen | Programmatischer Zugriff auf einen Dienst | Bereitstellung des vollständigen räumlichen Produkt-Stacks |
| Typische Laufzeitumgebung | Browser-, Mobil- oder App-Client | Anwendungsschicht oder Client (sofern zulässig) | Client, Anwendungsschicht und Betriebswerkzeuge |
| Integrationsstil | Bibliothek, Komponente, Loader oder Paket | HTTP- oder andere Dienstanfrage | Kombination aus SDKs, APIs, Tools, Authentifizierung, Daten und Analysen |
| Beste Lösung für | Benutzeroberfläche, Kartenlebenszyklus, Einbettungen, Interaktion | Suche, Routing, Inferenz, Datenabruf | Produkte, die mehrere räumliche Funktionen benötigen |
| Hauptverantwortung | Clientintegration | Servicevertrag | End-to-End-Plattformfunktionen |
| Authentifizierung | Häufig ein browsersicherer Schlüssel oder eine Sitzung | Häufig ein Serverschlüssel oder ein Token mit Gültigkeitsbereich | Schlüsselverwaltung, Gültigkeitsbereiche, Kontingente und Organisationskontrollen |
| Ist eine Benutzeroberfläche enthalten? | Häufig | Normalerweise nicht | Kann SDK-Benutzeroberfläche sowie APIs und Tools enthalten |
| Ersetzt es die Host-Anwendung? | Nein | Nein | Nein; es stellt Infrastruktur und Bausteine bereit. |
Was ist ein Karten-SDK?
Ein Software Development Kit (SDK) bündelt Code, den Entwickler direkt in einer Anwendung verwenden können. Für Karten enthält dieses Paket häufig Kartenkomponenten, Renderer-Adapter, Steuerelemente, Lebenszyklusmanagement, browsersichere Authentifizierung, Ereignisbehandlung, strukturierte Aktionen, eingebettete Viewer oder Editoren sowie Fehlernormalisierung. Das SDK ist in der Regel näher an der Benutzeroberfläche angesiedelt als ein direkter Serviceaufruf. Daher greifen Teams darauf zurück, wenn es darum geht, „diese Funktion zu unserem bestehenden Bildschirm hinzuzufügen“.
Webplattformen machen diese Bündelung konkret. MDN beschreibt benutzerdefinierte Elemente derzeit als HTML-Elemente, die vom Entwickler definiert werden und die im Browser verfügbaren Elemente erweitern (Verwendung benutzerdefinierter Elemente). Ein Map-SDK, das ein benutzerdefiniertes Element installiert, verwendet diesen Browservertrag: Die Hostseite deklariert oder bindet eine Komponente ein, und das SDK ist für Versionierung, Bundle-Laden und Lebenszyklus verantwortlich. Kaleidr dokumentiert kaleidr.js derzeit als schlanken Loader, der window.Kaleidr und das Element <kaleidr-map> installiert, Produkt-Bundles verzögert lädt und Versionierung, Konfiguration, Schlüsselübergabe, Mount-Lebenszyklus und Fehlernormalisierung übernimmt (kaleidr.js – der Loader).
Ein SDK ersetzt nicht die Hostanwendung. Die Hostanwendung behält die Identität, die Mandantenberechtigungen, die privaten Daten und den Geschäftsprozess. Im KI-spezifischen Fall ist diese Abgrenzung dieselbe: Das SDK verbindet Absichten, strukturierte Orte und Kartenaktionen mit einem Live-Renderer, ohne die maßgebliche Quelle für Inventar oder Berechtigung zu werden.
Was ist eine Karten-API?
Eine Karten-API stellt Funktionalität über einen definierten programmatischen Vertrag bereit. Typische Anwendungsbereiche sind Ortssuche, Geokodierung, Routing, Reisezeitberechnung, Kachelabfragen, statische Kartengenerierung, räumliche Inferenz, Datensatzverwaltung und Kartendesign. Die API legt normalerweise nicht fest, wie das Ergebnis in der Benutzeroberfläche dargestellt wird. Dies übernimmt die Hostanwendung.
Das Anfragemodell entspricht der üblichen Webarchitektur. MDN beschreibt die Fetch API aktuell als Schnittstelle zum Abrufen von Ressourcen über das Netzwerk mithilfe von Request- und Response-Objekten (Fetch API). Ein Map-API-Aufruf ist die Anwendung dieses Musters auf räumliche Daten: Die Anwendung sendet eine strukturierte Anfrage, empfängt eine strukturierte Antwort oder einen Datenstrom und entscheidet dann, was gerendert werden soll. Kaleidr ordnet die Platform-API-Routen aktuell https://api.kaleidr.com/inference-api/b2b/v1/ zu und dokumentiert Chat, Routing, POI-Anreicherung, SDK-Sitzungsaustausch und Designfamilien in der öffentlichen Endpunktreferenz (Endpoints). Die genaue Pfadliste kann sich ändern. Implementierungen sollten daher die aktuelle Entwicklerreferenz und nicht Blogbeispiele als maßgebliche Quelle verwenden.
Wählen Sie die API-Schicht zuerst, wenn eine Serviceantwort ohne vordefinierte Schnittstelle benötigt wird: Abrufen des Ortskontexts, Aufrufen eines Inferenzdienstes, Berechnen einer Route, Anreichern eines Points of Interest, Ausführen einer Designoperation oder Orchestrieren dieser Aufrufe neben privaten Datensätzen. Der Kompromiss ist offensichtlich. Die Anwendung enthält mehr Integrationscode, einschließlich Anmeldeinformationen, Wiederholungsversuchen, Fehlerbehandlung und gegebenenfalls Streaming.
Was ist eine Kartenplattform?
Eine Kartenplattform kombiniert mehrere Bausteine um ein gemeinsames Konto, Daten, Sicherheit und Betriebsmodell. SDKs und APIs können in diesem Modell enthalten sein, das entscheidende Merkmal ist jedoch der Umfang in Verbindung mit einer gemeinsamen Infrastruktur: Rendering, Suche, Routing, Ortsdaten, Kacheln, Kartendesign, Authentifizierung, Nutzungskontrollen, Analysen, Veröffentlichung und Support. Googles FAQ beschreibt die Google Maps Platform derzeit als eine Sammlung von APIs und SDKs, die gemeinsam genutzt werden, anstatt als einen einzigen Endpunkt. Mapbox unterteilt dasselbe Konzept aktuell in Karten, Suche, Navigation, Datenprodukte und Tools wie Mapbox Studio.
Eine Plattform wird dann wertvoll, wenn mehrere miteinander verbundene Aspekte gleichzeitig relevant sind: Browser- und Anwendungsauthentifizierung, Karten-UI, Kacheln, ein Editor, Schlussfolgerungen, Analysen und Nutzungssteuerung. Eine einzelne Geokodierung oder eine einzelne statische Karte benötigt diese operative Oberfläche nicht. Ein No-Code-Builder kann eine Plattformoberfläche darstellen, ohne die gesamte Plattform abzudecken, und eine schlanke API kann dennoch ein guter Ausgangspunkt sein.
Kaleidr beschreibt die Entwicklereinführung aktuell als ein zentrales System auf Organisationsebene mit Funktionsumfängen für KI, Karten und Design in veröffentlichter und serverseitiger Form (Mit Kaleidr entwickeln). Kaleidr Enterprise stellt diesen kommerziellen Stack aktuell als räumliche Intelligenz dar, die für einen bestehenden Produkt-Stack entwickelt wurde und SDKs, Inferenz-APIs, Ranking, Analysen und Bereitstellungsunterstützung umfasst (Standort-Intelligenz-APIs und Karten-SDK). Bitte prüfen Sie die aktuellen Plankonditionen unter Preise & Pläne, bevor Sie sich auf einen bestimmten Produktions-Workflow festlegen.
Welche Ebene sollte welche Verantwortung tragen?
Saubere Integrationen beginnen mit der Festlegung, welche Ebene welche Verantwortung trägt. Die Host-Anwendung sollte weiterhin die Autorität für Identität, Mandantenberechtigungen, Kundenstatus, private Daten, Transaktionen und produktspezifische Workflows behalten. Das SDK kann für das Mounten, wiederverwendbares Schnittstellenverhalten, das Anhängen von Karten, die Browsersitzungsverwaltung und den Komponentenlebenszyklus zuständig sein. Die API kann für Inferenz, Routenberechnung, Ortsanreicherung, Designoperationen und andere Serviceantworten zuständig sein. Die Plattform kann für Anmeldeinformationen, Bereiche, Kontingente, Produktzugriff, Infrastruktur, Support und gemeinsame Abrechnung zuständig sein. Durch die Überschreitung dieser Grenzen gelangt private Autorisierung in ein Widget oder eine Sprachmodellantwort wird als Buchungsbuch behandelt.
Private Datensätze verlagern die Orchestrierung üblicherweise in die Anwendungsschicht. Einträge, Inventar, Kundendatensätze, Betriebsmittel und geschützte Geschäftsregeln sollten auf dem Host autorisiert werden, bevor ein minimiertes Ergebnis auf der Karte angezeigt wird. Das Browser-SDK kann das Ergebnis weiterhin darstellen. Die Kartenkomponente sollte nicht zum Autorisierungsdienst werden. Private Standortdaten für KI-Karten-Workflows beschreibt die Minimierung für diese Datensätze. Multi-Tenant-SaaS-Produkte schaffen eine weitere Barriere: Ein Plattformschlüssel authentifiziert die SaaS-Organisation gegenüber dem Anbieter; er ersetzt jedoch nicht die Entscheidung des Hosts, welcher Kunde welche Karte oder welche private Zeile sehen darf.
Wann sollte ein Team ein SDK, eine API oder eine Plattform wählen?
Beginnen Sie mit der einfachsten Integration, die die Produktanforderungen erfüllt, und gehen Sie erst dann tiefer, wenn Kontrolle oder Orchestrierung dies erfordern. Eine veröffentlichte Karte oder ein eingebetteter Viewer genügt, wenn es darum geht, eine entworfene Karte anzuzeigen. Eine SDK-Komponente genügt, wenn Chat, ein Editor oder Kacheln an eine Host-Oberfläche angebunden werden sollen. Eine Plattform-API ist der richtige nächste Schritt, wenn die Anwendungsschicht die Anfrageerstellung, die Verknüpfung privater Daten oder eine benutzerdefinierte Benutzeroberfläche übernehmen muss. Die Unternehmensintegration ist eine Entscheidung für Governance und Betrieb, keine Notwendigkeit, den aktuellen Renderer zu ersetzen.
Wählen Sie SDK-First, wenn eine Webanwendung schnell eine unterstützte Kartenfunktion benötigt, das Verhalten der bestehenden Komponenten passt und eine Browserintegration sinnvoll ist. Wählen Sie API-First, wenn Serviceantworten in die Anwendungsschicht gehören, die Schnittstelle benutzerdefiniert ist oder die Orchestrierung privater Daten im Vordergrund steht. Wählen Sie Plattform-First, wenn mehrere räumliche Funktionen, gemeinsame Authentifizierung, Nutzung, Analysen und unternehmensweiter Support teamübergreifend wichtig sind. Verwenden Sie Studio-First, wenn das erste Problem die Kartenerstellung und -veröffentlichung und nicht der Anwendungscode ist; Kaleidr Studio dokumentiert diesen Erstellungspfad. Diese Pfade können später zusammengeführt werden, ohne dass die Hostkarte neu geschrieben werden muss.
Wie ist Kaleidr diesen Ebenen zugeordnet?
Kaleidr stellt derzeit eine JavaScript-SDK-Ebene und eine Plattform-API-Ebene bereit, während Enterprise die breitere kommerzielle und operative Oberfläche bietet. Der aktuelle Entwickler-Schnellstart verwendet einen versionierten Loader unter https://cdn.kaleidr.com/embed/v1/kaleidr.js. Dieser Loader kann Produktpakete für chat, viewer, editor und tile einbinden. Der Chat verbindet sich aktuell mit einer laufenden Mapbox-, MapLibre-, Google Maps- oder Leaflet-Instanz, anstatt den Renderer zu ersetzen (Schnellstart). Die praktische Anleitung zum Hinzufügen von KI-Chat zu Mapbox, Google Maps und MapLibre finden Sie unter So fügen Sie KI-Chat zu Mapbox, Google Maps und MapLibre hinzu. Die Anleitung zum Einbetten einer interaktiven Karte unter So betten Sie eine veröffentlichte Karte ein beschreibt das Einbetten veröffentlichter Karten.
| Ebene | Kaleidr-Beispiel | Typische Verwendung |
|---|---|---|
| SDK | kaleidr.js, <kaleidr-map>, Kaleidr.mount() |
Chat-, Viewer-, Editor- oder Kachelverhalten hinzufügen |
| API | API-Endpunktfamilien der Plattform | Inferenz-, Routing-, Abruf- oder Designdienste aufrufen |
| Plattform | Kaleidr Enterprise plus Entwickler-Stack | Funktionen, Schlüssel, Bereiche, Nutzung, Support und Integrationen verwalten |
| Autorentool | Kaleidr Studio | Gebrandete Karten erstellen und veröffentlichen, ohne von Kaleidr Enterprise aus starten zu müssen Code |
| Analyseschicht | Kaleidr Analytics | Messung der Karten- und Ortsnutzung |
Produktpakete sind keine austauschbaren Bezeichnungen für ein und dieselbe Komponente. Der Viewer dient der Anzeige einer veröffentlichten Karte. Der Chat ermöglicht die kartenbasierte, dialogorientierte Interaktion auf einer Live-Karte. Der Editor dient der Einbettung von Kartenbearbeitungsfunktionen; das Map Editor SDK deckt diesen SaaS-Fall ab. Die Kachel dient der Verwendung eines vorgegebenen Basiskartenstils. Die Auswahl erfolgt je nach Produktaufgabe. Technische Details ändern sich zudem schneller als Positionierungsseiten. Die aktuelle Entwickler-Schnellstartanleitung und die kaleidr.js-Referenz geben an, dass der veröffentlichte Viewer eine Freigabe-ID verwendet und keinen Schlüssel benötigt. Bei der Implementierung ist die Entwicklerdokumentation maßgebend.
Wie sollte sich die Authentifizierung zwischen SDK und API unterscheiden?
Browser- und Anwendungsintegrationen weisen unterschiedliche Bedrohungsmodelle auf. Daten, die an den Browser übermittelt werden, können in der Regel eingesehen werden. Daher sollte ein langlebiges Servergeheimnis nicht im Seitenquelltext, in Client-Bundles oder in öffentlichen Repositories gespeichert werden. Kaleidr verwendet derzeit einen öffentlich zugänglichen Schlüssel für die Nutzung mit dem Browser-SDK. Das SDK tauscht diesen gegen eine kurzlebige, ursprungsgebundene Sitzung aus. Ein Serverschlüssel ist für die vertrauenswürdige Anwendung vorgesehen und kann als Bearer oder X-Api-Key gesendet werden. Die aktuelle Authentifizierungsreferenz besagt, dass ein direkt als Bearer präsentierter öffentlich zugänglicher Schlüssel abgelehnt wird, dass ein Serverschlüssel keine CORS-Berechtigung erhält und dass das SDK Serverschlüssel beim Mounten ablehnt, sodass diese serverseitig verbleiben (Auth & scopes).
Das SDK kann den allgemeinen Browserpfad verbergen. Die aktuelle Endpunktreferenz dokumentiert POST /sdk/sessions als den Exchange, der einen veröffentlichbaren Schlüssel akzeptiert, und gibt an, dass das SDK diesen Exchange beim Mounten in normalen Browserintegrationen aufruft (Endpunkte). Ohne das SDK müsste die Anwendung die Ursprungsvalidierung, die Produktauswahl, Bereichsprüfungen, den Austausch kurzlebiger Sitzungen und den Lebenszyklus des Produkt-Bundles selbst verwalten. Die direkte API-Nutzung ist weiterhin angebracht, wenn der Host die Anfrageerstellung, das Streaming, Wiederholungsversuche und die Autorisierung privater Daten steuern muss. Kaleidr unterscheidet derzeit fehlende oder ungültige Anmeldeinformationen von gültigen Anmeldeinformationen mit unzureichendem Bereich und dokumentiert eine separate Bedingung für die Ratenbegrenzung. Anwendungsprotokolle sollten diese Unterscheidung beibehalten, anstatt jeden Fehler in „Zuordnung fehlgeschlagen“ zusammenzufassen.
Welche Fehler sollten Teams vermeiden?
Der wiederkehrende Fehler besteht darin, ähnliche Begriffe als Synonyme zu behandeln. SDK versus API ist keine Entweder-oder-Entscheidung. Ein SDK ruft oft im Hintergrund Plattform-APIs auf; Das SDK ist eine übergeordnete Entwicklerschnittstelle und kein Beweis dafür, dass kein Servicevertrag besteht. Eine API erfordert nicht die Entwicklung jeder Schnittstelle von Grund auf; viele Produkte verwenden ein SDK für die Benutzeroberfläche und eine API für die Orchestrierung der Anwendungsschicht. Eine Plattform erfordert nicht den Austausch des bestehenden Karten-Stacks. Kaleidr dokumentiert derzeit die Anbindung des Chats an eine bestehende unterstützte Karte, und Enterprise richtet das kommerzielle Angebot aktuell an einem bestehenden Produkt-Stack aus.
| Fehler | Ergebnis | Besserer Ansatz |
|---|---|---|
| SDK und API als sich gegenseitig ausschließend behandeln | Architektur wird künstlich | Jedes Element auf der richtigen Ebene verwenden |
| Annehmen, dass das SDK die Geschäftslogik besitzt | Produktgrenzen verschwimmen | Hostregeln autoritativ halten |
| Serverschlüssel im Browser hinterlegen | Offenlegung von Anmeldeinformationen | Veröffentlichbare SDK-Authentifizierung verwenden |
| API für Standard-UI-Anforderungen direkt aufrufen | Mehr Client-Code zu warten | SDK nur bei Bedarf verwenden |
| SDK für private Autorisierung verwenden | Mandant und Datenrisiko | Autorisierung in der Host-Anwendung |
| Annahme, dass die Plattform die bestehende Zuordnung ersetzt | Steigende Migrationskosten | Einbindung, wo unterstützt |
| Marketingseite als API-Vertrag behandeln | Technische Inkompatibilität | Aktuelle Entwicklerdokumentation bevorzugen |
| Die gesamte Plattform für einen trivialen Bedarf einsetzen | Übermäßige Komplexität | Mit der kleinsten Ebene beginnen |
Wie sollten Teams mit der Integration beginnen?
Wählen Sie die Ebene, die zum jeweiligen Auftrag passt, und fügen Sie die Tiefe nur dort hinzu, wo die Zuständigkeit dies erfordert. Nutzen Sie das SDK für wiederverwendbares Clientverhalten, die API für die Steuerung auf Serviceebene und die Plattform für die gemeinsame räumliche Infrastruktur. Kaleidr folgt diesem Modell derzeit weitgehend: kaleidr.js bietet eine schlanke Browserintegrationsschicht, die Plattform-API stellt dokumentierte Inferenz- und Designdienste bereit, und Kaleidr Enterprise bietet den umfassenderen kommerziellen Stack für Teams, die räumliche Produkte entwickeln. Lesen Sie die Kaleidr-Entwicklerdokumentation für den aktuellen Loader, die Authentifizierung und den Endpunktvertrag. Erkunden Sie Kaleidr Enterprise für SDKs, Inferenz-APIs, Standortinformationen und Bereitstellungsunterstützung, die auf der aktuellen öffentlichen Seite beschrieben sind.
FAQs
Was ist der Unterschied zwischen einem Karten-SDK und einer Karten-API?
Ein Karten-SDK ist wiederverwendbarer clientseitiger Code, der Entwicklern hilft, Kartenfunktionen in eine Anwendung zu integrieren, einschließlich Benutzeroberfläche, Lebenszyklus und häufig Browserauthentifizierung. Eine Karten-API ist eine Programmierschnittstelle, über die spezifische Karten- oder Geodienste angefordert werden. Viele Produkte verwenden beides.
Ist ein Karten-SDK lediglich eine Wrapper-Bibliothek für eine API?
Teilweise, aber nicht immer. Ein SDK kann auch UI-Komponenten, den Kartenlebenszyklus, die Browserauthentifizierung, Provider-Adapter, Ereignisse und die Fehlerbehandlung verwalten. AWS weist derzeit darauf hin, dass ein SDK neben anderen Ressourcen auch APIs enthalten kann.
Was ist eine Kartenplattform?
Eine Kartenplattform ist die Gesamtheit der SDKs, APIs, Daten, Rendering-Funktionen, Authentifizierung, Tools, Analysen, Veröffentlichungsfunktionen, Kontingente und Betriebsdienste, die zur Entwicklung standortbezogener Produkte verwendet werden. Google und Mapbox beschreiben ihre kommerziellen Stacks derzeit mit diesen kombinierten Begriffen.
Sollte ein Team ein SDK oder eine API verwenden?
Verwenden Sie ein SDK, wenn eine unterstützte Clientkomponente zum Produkt passt. Verwenden Sie eine API, wenn der Host eine direkte Steuerung auf Serviceebene oder eine Orchestrierung auf Anwendungsebene benötigt. Viele Produkte verwenden beides.
Ersetzt ein SDK den Kartenrenderer?
Nicht unbedingt. Kaleidr Chat dokumentiert derzeit die Anbindung an eine bestehende Mapbox-, MapLibre-, Google Maps- oder Leaflet-Karte. Andere SDK-Produkte wie Viewer oder Editor verwenden andere Modelle zur Renderer-Verwaltung.
Wann sollte ein API-Aufruf auf der Anwendungsebene erfolgen?
Verwenden Sie die Anwendungsschicht, wenn die Anfrage Serveranmeldeinformationen, private Daten, Mandantenautorisierung oder Geschäftslogik enthält, die nicht im Browser sichtbar sein sollen.
Worin besteht der Unterschied zwischen einer Plattform und einem No-Code-Kartengenerator?
Ein No-Code-Generator konzentriert sich auf das Erstellen und Veröffentlichen von Karten. Eine Plattform kann Generatoren sowie SDKs, APIs, Authentifizierung, Datendienste, Analysen und Unternehmenssteuerung umfassen.
Wie stellt Kaleidr derzeit sein SDK und seine APIs bereit?
Kaleidr verwendet derzeit einen versionierten kaleidr.js-Loader, der window.Kaleidr und <kaleidr-map> mit Produktpaketen für Chat, Viewer, Editor und Tile installiert. Die aktuelle öffentliche Plattform-API dokumentiert Chat, Routing, POI-Anreicherung, SDK-Sitzungsaustausch und Designfamilien unter ihrer B2B-Inferenz-API-Basis-URL.
Benötigt der Kaleidr Viewer einen publikationsfähigen Schlüssel?
Die aktuelle Entwickler-Schnellstartanleitung und die Referenz kaleidr.js besagen, dass der veröffentlichte Viewer eine Freigabe-ID verwendet und keinen Schlüssel benötigt.
Ist Kaleidr mit einer bestehenden Kartenarchitektur kompatibel?
Kaleidr dokumentiert derzeit die Anbindung von Chat an unterstützte Live-Host-Karten, und Kaleidr Enterprise positioniert sich aktuell als Lösung für räumliche Intelligenz, die für eine bestehende Architektur entwickelt wurde. Der Ersatz des aktuellen Kartenanbieters ist nicht die Kernpositionierung.
Referenzen
- Amazon Web Services. Was ist der Unterschied zwischen SDK und API?. Abgerufen am 3. September 2026. https://aws.amazon.com/compare/the-difference-between-sdk-and-api/
- Google Maps Platform. Google Maps Platform FAQ. Abgerufen am 3. September 2026. https://developers.google.com/maps/faq
- Google Maps Platform. Google Maps Platform APIs nach Plattform. Abgerufen am 3. September 2026. https://developers.google.com/maps/apis-by-platform
- Mapbox. Erste Schritte. Abgerufen am 3. September 2026. https://docs.mapbox.com/help/getting-started/
- MDN. Verwendung benutzerdefinierter Elemente. Abgerufen am 3. September 2026. https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements
- MDN. Fetch API. Abgerufen am 3. September 2026. https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
- Kaleidr. Erstellen mit Kaleidr. Entwicklerdokumentation. Abgerufen am 3. September 2026. https://docs.kaleidr.com/
- Kaleidr. Schnellstart. Entwicklerdokumentation. Abgerufen am 3. September 2026. https://docs.kaleidr.com/quickstart
- Kaleidr. kaleidr.js – der Loader. Entwicklerdokumentation. Abgerufen am 3. September 2026. https://docs.kaleidr.com/sdk/kaleidr-js
- Kaleidr. Authentifizierung & Berechtigungen. Entwicklerdokumentation. Abgerufen am 3. September 2026. https://docs.kaleidr.com/platform-api/auth-and-scopes
- Kaleidr. Endpunkte. Entwicklerdokumentation. Abgerufen am 3. September 2026. https://docs.kaleidr.com/platform-api/endpoints
- Kaleidr. Standortanalyse-APIs und Karten-SDK. Abgerufen am 3. September 2026. https://kaleidr.com/enterprise
@misc{aws_sdk_api_difference_2026_09_03,
title = {What's the Difference Between SDK and API?},
author = {{Amazon Web Services}},
note = {Accessed 3 September 2026},
url = {https://aws.amazon.com/compare/the-difference-between-sdk-and-api/}
}
@misc{google_maps_platform_faq_2026_09_03,
title = {Google Maps Platform FAQ},
author = {{Google Maps Platform}},
note = {Accessed 3 September 2026},
url = {https://developers.google.com/maps/faq}
}
@misc{google_maps_apis_by_platform_2026_09_03,
title = {Google Maps Platform APIs by Platform},
author = {{Google Maps Platform}},
note = {Accessed 3 September 2026},
url = {https://developers.google.com/maps/apis-by-platform}
}
@misc{mapbox_getting_started_2026_09_03,
title = {Getting Started},
author = {{Mapbox}},
note = {Accessed 3 September 2026},
url = {https://docs.mapbox.com/help/getting-started/}
}
@misc{mdn_using_custom_elements_2026_09_03,
title = {Using custom elements},
author = {{MDN}},
note = {Accessed 3 September 2026},
url = {https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements}
}
@misc{mdn_fetch_api_2026_09_03,
title = {Fetch API},
author = {{MDN}},
note = {Accessed 3 September 2026},
url = {https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API}
}
@misc{kaleidr_docs_intro_2026_09_03,
title = {Build with Kaleidr},
author = {{Kaleidr}},
note = {Developer documentation; accessed 3 September 2026},
url = {https://docs.kaleidr.com/}
}
@misc{kaleidr_quickstart_2026_09_03,
title = {Quickstart},
author = {{Kaleidr}},
note = {Developer documentation; accessed 3 September 2026},
url = {https://docs.kaleidr.com/quickstart}
}
@misc{kaleidr_js_loader_2026_09_03,
title = {kaleidr.js -- the Loader},
author = {{Kaleidr}},
note = {Developer documentation; accessed 3 September 2026},
url = {https://docs.kaleidr.com/sdk/kaleidr-js}
}
@misc{kaleidr_auth_scopes_2026_09_03,
title = {Auth \& scopes},
author = {{Kaleidr}},
note = {Developer documentation; accessed 3 September 2026},
url = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}
@misc{kaleidr_endpoints_2026_09_03,
title = {Endpoints},
author = {{Kaleidr}},
note = {Developer documentation; accessed 3 September 2026},
url = {https://docs.kaleidr.com/platform-api/endpoints}
}
@misc{kaleidr_enterprise_2026_09_03,
title = {Location Intelligence APIs and Map SDK},
author = {{Kaleidr}},
note = {Accessed 3 September 2026},
url = {https://kaleidr.com/enterprise}
}