MICROSOFT SQL SERVER
REST-API
Wandeln Sie eine Microsoft SQL Server-Abfrage in eine sichere REST-API — kein Data API Builder, kein Server zum Hosten.
Speichern Sie eine T-SQL-Abfrage für Ihre SQL-Server-Datenbank, erstellen Sie einen API-Schlüssel pro Empfänger und stellen Sie einem Partner einen aktiven JSON-Endpunkt zur Verfügung. Nein Daten-API-Generator zum Bereitstellen, kein offener 1433 Port, kein gemeinsamer Login – nur ein verwalteter, schreibgeschützter Zugang SQL Server REST-API in Minuten.
Fragen Sie Nova und erhalten Sie SQL + Diagramme
Treffen mit Nova
Ein Schlüssel pro Partner. Zugangsdaten werden nicht weitergegeben.
Erstellen Sie eine API
+mehr
Geplante Synchronisierung mit 6+ Plattformen
Erkunden Sie
+mehr
Abfrage von APIs mit SQL, ohne Code
Erkunden Sie
+mehr
Claude, Cursor, ChatGPT & Grok sprechen mit Ihren Daten
Connect AIQuery Streams ist eine sichere Echtzeit-Datenbankintegrationsplattform, die jede gespeicherte SQL Server-Abfrage in einen partnerfähigen REST-API-Endpunkt umwandelt – mit empfängerspezifischen Schlüsseln, Schreibschutz und einem vollständigen Prüfprotokoll. Du bekommst ein Live-Video SQL Server REST-API (ein sauberes REST-API für SQL Server) ohne den Data API Builder bereitzustellen, einen Datenbankport zu öffnen oder ein Gateway zu hosten. Weitere Informationen finden Sie unter QueryStreams.com. und kostenlos anmelden Veröffentlichen Sie Ihren ersten SQL Server-Endpunkt in wenigen Minuten.
Warum sollte man eine Microsoft SQL Server-Datenbank als REST-API bereitstellen?
Früher oder später benötigt jemand außerhalb Ihres Teams Daten, die in Microsoft SQL Server gespeichert sind – ein Kunde möchte seine Zahlen in einem Dashboard sehen, ein Lieferant wünscht sich einen Live-Feed anstelle eines nächtlichen Exports, die App eines Partners muss einen Teil Ihrer Tabellen lesen. Die üblichen Lösungsansätze bergen alle Risiken. Sie versenden Exporte per E-Mail, die bereits veraltet sind, Sie geben einen schreibgeschützten SQL-Login aus, der über die Projektlaufzeit hinaus gültig ist, oder Sie implementieren den Data API Builder oder eine ASP.NET Web-API und übernehmen deren Authentifizierung, TLS und Patching auf Dauer. Eine SQL-Server-Datenbank als REST-Dienst bereitstellen Die saubere Methode: Der Partner erhält eine URL und ein Token, nicht Ihre Datenbank. Die Herausforderung bestand bisher darin, diese API sicher zu entwickeln und zu betreiben. Query Streams vereinfacht dies durch eine gespeicherte Abfrage und einen zugehörigen Schlüssel.
Kein offener SQL Server-Port
Du legst niemals offen 1433 Um ins Internet zu gelangen oder eine Sicherheitslücke in Ihrer Firewall zu öffnen, wählt der Netzwerkagent eine Verbindung; eingehende Anrufe werden über diese eine ausgehende Verbindung zurückgeleitet.
API-Schlüssel pro Empfänger
Jeder Empfänger erhält sein eigenes qsapi_* Schlüssel. Widerrufen Sie einen, ohne die anderen zu berühren und ohne Ihre SQL Server-Anmeldung zu ändern.
Designbedingt schreibgeschützt
Ein Validator für schreibgeschützte Anweisungen weist jede Nicht-SELECT-Anweisung zurück, bevor sie den SQL Server erreicht. Es gibt keine versehentlichen Fehler. AKTUALISIEREN, VERSCHMELZEN, oder FALLEN Pfad durch die API.
Ihr T-SQL-Code bleibt privat
Der Empfänger sieht die Endpunkt-URL, die JSON-Antwort und alle von Ihnen freigegebenen Filter – niemals Ihr T-SQL, Schema, Instanznamen oder Ihre Verbindungszeichenfolge.
Nichts zu hosten oder zu patchen
Kein Data API Builder-Container, keine ASP.NET-Anwendung, kein Reverse-Proxy. Der Endpunkt läuft als verwaltetes Feature, daher gibt es keine Bereitstellungspipeline oder TLS-Rotation, für die Sie verantwortlich sein müssen.
permanent, ablaufend oder selbstzerstörend
Einen Endpunkt dauerhaft machen, ein Ablaufdatum festlegen oder ein festes Anrufbudget zuweisen, das sich nach einer bestimmten Anzahl von Anfragen selbst zerstört.
Die üblichen Methoden zur Implementierung einer REST-API auf SQL Server – und warum sie schädlich sind
Es gibt bekannte Werkzeuge zum Erstellen eines SQL Server Web-APIUnd sie sind gut in dem, was sie tun. Der Haken dabei ist, dass Sie bei jeder dieser Lösungen die Infrastruktur, ein gewisses Netzwerkrisiko oder beides selbst tragen müssen. Im Folgenden wird der Vergleich der gängigen Ansätze mit einem gemeinsam genutzten Query-Streams-Endpunkt erläutert, wenn das Ziel lediglich darin besteht, „einem bestimmten Partner das Lesen eines bestimmten Ergebnissatzes zu ermöglichen“.
| Sorge | Microsoft Data API Builder | DIY ASP.NET Web-API | Abfrageströme |
|---|---|---|---|
| Die Datenbank ist über die API erreichbar. | Der Host muss den SQL Server erreichen können. | SQL Server muss erreicht werden | Agent nur für ausgehende Verbindungen – kein eingehender Port |
| Was der Empfänger in Händen hält | Eine URL zu Ihren exponierten Entitäten | Eine URL zu Ihrem Dienst | Ein Schlüssel für einen einzigen Zweck für eine Abfrage |
| Schemadarstellung | Jede konfigurierte Entität ist erreichbar. | Was auch immer Sie von Hand codieren | Eine gespeicherte Abfrage, sonst nichts. |
| Empfängerspezifische Schlüssel + Widerruf | Richten Sie Ihre eigene Authentifizierung ein. | Bau es selbst | Eingebaut |
| Audit-Protokoll jedes Anrufs | Füge es selbst hinzu | Füge es selbst hinzu | Eingebaut |
| Sie betreiben/patchen/rotieren TLS | Ja, für immer. | Ja, für immer. | Für Sie verwaltet |
| Zeit bis zum ersten Endpunkt | Stunden bis Tage | Tage | Minuten |
Suchen Sie eine Alternative zum Data API Builder für die Partnerfreigabe?
Microsoft Data API Builder eignet sich hervorragend, wenn Sie eine vollständige, selbstgehostete REST- und GraphQL-Schnittstelle für Ihre eigenen Entitäten benötigen. Wenn Sie hingegen einem benannten Partner ein verwaltetes, schreibgeschütztes Ergebnis-Set – mit eigenem Schlüssel, Audit-Trail und ohne auszuführenden Host – bereitstellen möchten, schließt Query Streams genau diese Lücke. Beide können parallel genutzt werden: Data API Builder für Ihre interne Anwendung, Query Streams für die externe Weitergabe.
Wie Query Streams eine SQL-Server-Abfrage in eine REST-API umwandelt
Sobald der Netzwerkagent installiert und Ihr SQL-Server-Connector konfiguriert ist, sind für die Übertragung einer gespeicherten Abfrage an einen gemeinsam genutzten REST-Endpunkt etwa drei Schritte erforderlich. Wenn Sie bereits Query Streams für Excel, Google Sheets oder den MCP-Server verwenden, sind Agent und Connector bereits vorhanden – Sie beginnen mit Schritt zwei.
Stellen Sie eine Verbindung zum SQL Server über den Agenten her.
Installieren Sie den Netzwerkagenten neben Ihrer Datenbank und fügen Sie einen SQL Server-Connector mit einem standardmäßigen schreibgeschützten Login hinzu. Der Agent stellt eine ausgehende TLS-Verbindung zu Query Streams her – Ihre Datenbank ist niemals dem Internet ausgesetzt.
Speichern einer T-SQL-Abfrage
Schreibe die SELECT Im Abfrage-Generator für Ihre SQL-Server-Verbindung sind JOINs, CTEs, Fensterfunktionen und Parameter willkommen. Benennen Sie die Abfrage und speichern Sie sie. Alles, was Sie mit SELECT abfragen können, kann zu einem Endpunkt werden.
Bewerben Sie es und teilen Sie einen Schlüssel
Öffnen Sie den Tab „Installieren“, wählen Sie den Endpunkttyp (permanent, zeitlich begrenzt oder Anrufbudget) und das Ausgabeformat aus und laden Sie anschließend einen Empfänger per E-Mail ein. Dieser erhält einen Magic-Link-Claim und seine eigene qsapi_* Schlüssel.
Eine gespeicherte Abfrage, viele Oberflächen
Dieselbe gespeicherte SQL-Server-Abfrage kann eine Aktualisierung von Excel, eine Seitenleiste in Google Sheets oder eine Konversation mit Claude oder Cursor über den MCP-Server auslösen. und Gleichzeitig wird ein REST-Endpunkt für Partner bereitgestellt. Sie erstellen die Abfrage einmalig; Query Streams kümmert sich um die Schnittstellen.
Kein offener SQL-Server-Port, keine gemeinsam genutzten Anmeldeinformationen
Das Sicherheitsmodell ist der Grund, warum Teams diese Lösung einem öffentlichen Datenbankport vorziehen. Ihre SQL-Server-Anmeldeinformationen befinden sich ausschließlich im verschlüsselten Anmeldeinformationsspeicher des Agenten in Ihrem Netzwerk; sie werden niemals an unsere Cloud übertragen und sind für Empfänger niemals sichtbar. Darüber hinaus bietet Ihnen jeder Endpunkt individuelle Steuerungsmöglichkeiten für jeden Empfänger, die Sie vor der Freigabe anpassen können.
Agent für ausgehende Anrufe
Der Agent stellt die Verbindung über Port 443 her – normales ausgehendes HTTPS, keine eingehenden Ports, VPN oder Tunnel. warum keine eingehende Exposition erforderlich ist →
Nur-Lese-Durchsetzung
Ein Validator wird im Agenten in Ihrem Netzwerk ausgeführt, bevor eine Anweisung den SQL Server erreicht. Nicht-SELECT-Anweisungen werden mit folgender Fehlermeldung zurückgewiesen: READONLY_VIOLATION.
IP- und CORS-Zulassungslisten
Binden Sie den Schlüssel eines Empfängers an bestimmte IP-Adressen oder CIDR-Bereiche an und beschränken Sie, welche Browser die einzelnen Endpunkte aufrufen dürfen. Aufrufe von nicht zugeordneten Adressen werden vor der Ausführung von SQL-Abfragen abgelehnt.
Ratenbegrenzungen + Byte-Kontingente
Zweistufige Ratenbegrenzungen (pro Schlüssel und pro Endpunkt) sowie eine optionale monatliche Byte-Obergrenze sorgen dafür, dass ein unkontrollierter oder außer Kontrolle geratener Empfänger innerhalb eines sicheren Gefahrenbereichs bleibt.
Rufen Sie Ihre SQL Server REST-API auf.
Empfänger rufen den Endpunkt wie jede andere REST-API auf: mit einem Bearer-Token und einer URL. Jeder gespeicherte Abfrageparameter, den Sie freigegeben haben, kann pro Aufruf – in der Abfragezeichenfolge – festgelegt werden. ERHALTEN oder in einem JSON-Body für POSTDer Agent bindet diese Werte als ordnungsgemäße parametrisierte Abfrageparameter, niemals als Zeichenkettenverkettung, sodass ein Empfänger nicht aus einem Filter ausbrechen kann, um SQL einzuschleusen.
Wählen Sie das Ausgabeformat pro Aufruf mit der Akzeptieren Kopfzeile (oder ein ?format= Abfrageparameter): JSON für ein einzelnes Array, CSV für Tabellenkalkulationen und Pandas oder auf einem Streaming-Endpunkt, NDJSON (Eine JSON-Zeile pro Zeile) für Parse-as-you-go-Pipelines. Für bandbreitenempfindliche Nutzer: Option aktivieren LZ4 Nutzlastkomprimierung mit Accept-Encoding: lz4; unkomprimierte Antworten erhalten ebenfalls Standardwerte gzip Die Übertragung erfolgt automatisch. Eine detaillierte Aufschlüsselung der statischen und Streaming-Modi, der vier Drahtkombinationen und der OpenAPI 3.1-Generation finden Sie unter [Link einfügen]. Sofortige REST-API für SQL-Datenbanken Führung.
Wie die Nutzung abgerechnet wird
Die API-Plattform ist in jedem Tarif enthalten und nutzt das gleiche monatliche Datenvolumen wie Excel, Sheets und MCP. lz4 Anrufe werden auf Basis der verschobenen komprimierten Bytes abgerechnet, ansonsten auf Basis der unkomprimierten Bytes. Wie die bytebasierte Abrechnung plattformübergreifend funktioniert →
Integrieren Sie es in Power BI, Tableau und alle Programme, die JSON lesen können.
Weil jeder Endpunkt einen Standard zurückgibt JSON — mit CSV und Streaming-NDJSON im Angebot — jedes Tool, das einen REST-Feed lesen kann, kann Ihre SQL Server-Daten direkt verarbeiten, ohne dass auf deren Seite etwas installiert werden muss und kein SQL-Treiber erforderlich ist. Power-Abfrage ist der einfachste Einstieg in die Microsoft BI-Welt: in Power BI wählen Daten abrufen → Aus dem WebFügen Sie die Endpunkt-URL ein und fügen Sie Ihre Genehmigung Die Kopfzeile und Power Query parsen das JSON in eine aktualisierbare Tabelle, die Ihr Datenmodell speist. (Für Live-Daten in einer Tabellenkalkulation, die native Query Streams Excel-Add-on ist der einfachere Weg – Power Query steht Ihnen zur Verfügung, wenn Sie die Daten direkt im Power BI-Modell benötigen.)
Power-Abfrage
Daten abrufen → Aus dem Web: URL und Bearer-Token einfügen, JSON in eine aktualisierbare Tabelle erweitern.
Power BI
Dieselbe Power Query-Engine – laden Sie den Endpunkt direkt in Ihr Modell und planen Sie die Aktualisierung.
Tableau
Verbinden Sie einen Webdatenkonnektor oder eine JSON-Quelle mit dem Endpunkt, um Live-Dashboards anzuzeigen.
Briefträger
Importieren Sie die OpenAPI 3.1-Spezifikation und senden, prüfen und teilen Sie dann Anfragen mit einem Klick.
Es ernährt auch n8n, Qlik, Locke, Python (Anfragen oder pandas.read_json), Insomnia, Hoppscotch — oder jedes Skript oder jeder Workflow, der eine HTTP-Anfrage senden und JSON lesen kann.
Funktioniert auch mit Azure SQL und verwaltetem SQL Server.
Es spielt keine Rolle, wo Ihr SQL Server ausgeführt wird. Der Agent verbindet sich auf dieselbe Weise mit einer lokalen Instanz oder einem verwalteten Dienst – Azure SQL-Datenbank, Azure SQL Managed Instance oder Amazon RDS für SQL Server. Um die geringste Latenz zu erzielen, stellen Sie den Agent im selben Netzwerk oder in derselben Region wie die Datenbank bereit. Ein Query Streams-Konto kann mehrere Agents regions- und cloudübergreifend ausführen, und ein einzelner Endpunkt verhält sich unabhängig vom verwendeten Agent identisch.
Mehr als SQL Server
Derselbe Workflow ermöglicht es, eine gespeicherte Abfrage von PostgreSQL, MySQL, Oracle, Snowflake, BigQuery, DuckDB und anderen Datenbanken an einen REST-Endpunkt weiterzuleiten – SQL Server ist nur ein beliebter Ausgangspunkt. jede Datenbank, die die API-Plattform unterstützt →
Häufig gestellte Fragen
Muss ich einen Port öffnen oder den SQL Server dem Internet zugänglich machen? +
1433 (standardmäßig) wird niemals offengelegt und es ist keine eingehende Firewall-Regel erforderlich. wie die ausschließlich ausgehende Verbindung funktioniert →Kann der Empfänger meine T-SQL- oder meine Datenbankzugangsdaten einsehen? +
Worin unterscheidet sich dies vom Microsoft Data API Builder? +
Welche Ausgabeformate kann die API zurückgeben? +
Akzeptieren Kopfzeile oder ein ?format= Parameter, mit optionaler LZ4-Nutzlastkomprimierung. die Ausgabeformate und Drahtkombinationen erklärt →Können die Empfänger die Ergebnisse filtern oder erhalten sie eine feste Abfrage? +
ERHALTEN, JSON-Body für POST), und der Agent bindet jeden Wert als echten Abfrageparameter, sodass Filter kein SQL einschleusen können. wie exponierte Parameter und sichere Bindung funktionieren →Kann ein Endpunkt ablaufen oder sich selbst zerstören? +
Funktioniert es mit Azure SQL-Datenbank oder Amazon RDS für SQL Server? +
Benötigt der Empfänger ein Query Streams-Konto? +
Los geht's
Veröffentlichen Sie Ihre erste SQL Server REST-API kostenlos.
Registrieren Sie sich, installieren Sie den Netzwerkagenten neben Ihrer SQL-Server-Datenbank, speichern Sie eine T-SQL-Abfrage und senden Sie einem Empfänger einen Magic-Link-Claim per E-Mail. Empfängerspezifische Schlüssel, Schreibschutz und ein vollständiges Audit-Protokoll sind ab dem ersten Aufruf aktiviert.
Verwandte Leitfäden: Sofortige REST-API für SQL-Datenbanken | Datenbank-REST-API-Plattform | PostgreSQL als REST-API bereitstellen | Anleitungen zur Konnektoreinrichtung
Kategorie: API-Plattform
Tags: sql-server-rest-api, mssql-rest-api, rest-api-for-sql-server, sql-server-web-api, data-api-builder-alternative, expose-sql-server-as-api, share-sql-server-data, per-recipient-keys, no-code-api, database-rest-api
Meta-Beschreibung: Verwandeln Sie eine SQL-Server-Abfrage in eine sichere, schreibgeschützte REST-API mit empfängerspezifischen Schlüsseln – ohne Data API Builder, ohne offenen Port, ohne Code.
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish