REST APIs
REST (REpresentational State Transfer) ist eine einfache zustandslose Architektur, die Standards zwischen Computersystemen im Web bereitstellt, sodass sie leichter miteinander kommunizieren können.
Now Platform stellt verschiedene REST APIs bereit, die standardmäßig aktiv sind. Diese APIs bieten die Möglichkeit, mit verschiedenen Funktionen von ServiceNow in Ihrer Anwendung zu interagieren. Zu diesen Funktionen gehört die Möglichkeit, CRUD-Vorgänge (Create, Read, Update, Delete, also Erstellen, Lesen, Aktualisieren, Löschen) für vorhandene Tabellen auszuführen (Tabellen-API), Daten in MetricBase-Datenbanken einzufügen, Informationen aus diesen abzurufen und Transformationen für MetricBase-Datenbanken auszuführen (MetricBase Time Series-API und viele andere).
Eine Liste der verfügbaren REST APIs finden Sie in der REST API-Referenz.
https://<instancename>.service-now.com/syslog_transaction_list.do?sysparm_query=sys_created_onONToday%40javascript%3Ags.beginningOfToday()%40javascript%3Ags.endOfToday()%5Etype%3Drest
REST URI-Format und verfügbare Parameter
ServiceNow-REST APIs folgen dem REST API-Standardprotokoll. Sie stellen auch „benutzerdefinierte“ URI- und Abfrageparameter bereit, um die Abwärtskompatibilität sicherzustellen, und bieten zusätzliche Funktionen wie die Paginierung langer Ergebnislisten. In den folgenden Abschnitten wird die Funktionalität dieser benutzerdefinierten Parameter beschrieben, die allesamt optional sind.
REST API-Versionsverwaltung
URIs von ServiceNow-REST APIs können eine Versionsnummer enthalten, z. B. /api/now/v1/table/{tableName}. Versionsnummern identifizieren die Endpunktversion, auf die ein URI zugreift. Durch Angabe einer Versionsnummer in Ihren URIs können Sie sicherstellen, dass zukünftige Aktualisierungen der REST API sich nicht negativ auf Ihre Integration auswirken.
URIs ohne Versionsnummer im URI, z. B. /api/now/table/{tableName}, verwenden für Ihre Instanzversion den neuesten REST-Endpunkt.
Unterstützte HTTP-Anforderungsmethoden
- GET
- DELETE
- HEAD
- PATCH
- POST
- PUT
Weitere Informationen zu diesen Methoden finden Sie im Dokument RFC-2616 Hypertext Transfer Protocol.
- Sie können HEAD-Methoden anstelle von GET-Methoden verwenden, um eine Antwort ohne Antworttext zurückzugeben.
- In POST-, PUT- und PATCH-Vorgängen können nicht mehrere Datensätze übergeben werden. Wenn Sie dies versuchen, wird nur der erste Datensatz verarbeitet, der Rest wird ignoriert.
- Sie können POST, PUT und PATCH nicht zum Einfügen oder Aktualisieren von Datensätzen in Datenbankansichten verwenden, da Datenbankansichten schreibgeschützt sind.
Datenformat-Header
REST APIs erfordern die Anforderungsheader Accept und Content-Type zur korrekten Datenformatierung von Anforderungen, die einen Anforderungstext oder einen Antworttext enthalten. Für die Operationen POST, PUT, PATCH und DELETE müssen Sie beide Header angeben. Für GET- und HEAD-Vorgänge ist nur der Header Accept erforderlich. Wenn Sie die erforderlichen Header nicht angeben, wird der Fehler 400 Fehlerhafte Anforderung ausgegeben.
Für die meisten ServiceNow-REST APIs unterstützen diese Anforderungsheader die folgenden Werte:
- Accept: application/json, application/xml
- Inhaltstyp: application/json, application/xml
Eine Liste der spezifischen Werte, die von jedem Endpunkt unterstützt werden, finden Sie in der REST API-Referenz.
Weitere Header
Alle Anforderungen enthalten möglicherweise einen Authentifizierungsheader, der die Benutzeranmeldeinformationen zur Authentifizierung angibt.
Sie können HTTP-Methoden wie GET und POST überschreiben, indem Sie den Header X-http-method-override setzen.
Spezielle Datenbearbeitung
Im Folgenden werden einige der Datenbearbeitungsnuancen innerhalb der REST API beschrieben.
- Datenfeld löschen: Mit Ausnahme von Auswahlfeldern können Sie im Parameter einen leeren Wert übergeben, um den Wert in der Datenbank zu löschen. Wenn Sie beispielsweise
{"short description":""}senden, wird das Feld short_description für den angegebenen Datensatz gelöscht. - Währungsfelder behandeln: Zurückgegebene Währungswerte werden basierend auf dem Gebietsschema des Benutzers in die lokale Währung umgerechnet. Beim Einfügen von Daten findet keine Umrechnung statt. Dieses Verhalten gilt für Felder vom Typ
CurrencyundPrice.Wenn beispielsweise ein Benutzer im Gebietsschema „UK“ Datensätze mit Währungswerten in USD abfragt, werden die zurückgegebenen Werte in GBP umgerechnet. Wenn dieser Benutzer jedoch einen neuen Datensatz mit dem Währungsfeldwert in GBP hinzufügt, wird der Wert in GBP gespeichert und nicht in USD umgerechnet. Dieser GBP-Wert wird in USD angezeigt, wenn er von einem Benutzer im US-Gebietsschema abgefragt wird.
- UI-Datenanzeige und in einem REST-Endpunkt übergebene Werte: Die UI zeigt den Anzeigewert der Datenbank an, bei dem es sich um manipulierte Daten handelt. Ein REST-Endpunkt fügt standardmäßig die tatsächlichen Werte ein und aktualisiert sie. Diese können jedoch vom Anzeigewert abweichen. Sie können einen REST-Endpunkt zwingen, übergebene Werte als Anzeigewerte zu behandeln, indem Sie den Anforderungsparameter sysparm_input_display_value auf „true“ setzen.
Benutzerdefinierte Abfrageparameter
Die ServiceNow-REST APIs verwenden die folgenden Abfrageparameter für viele der verfügbaren APIs, um ein konsistentes Verhalten über die APIs hinweg zu gewährleisten. Verwenden Sie diese Parameter, um große Datensätze zu paginieren, Ergebnisse zu filtern und die Anzahl der in einer einzelnen Abfrage zurückgegebenen Datensätze zu beschränken.
| sysparm_limit | Maximale Anzahl der zurückzugebenden Datensätze. Verwenden Sie für Anforderungen, die diese Anzahl von Datensätzen überschreiten, den Parameter sysparm_offset, um den Datensatzabruf zu paginieren. Dieser Grenzwert wird vor der ACL-Bewertung angewendet. Erfolgt keine Datensatzrückgabe, einschließlich Datensätzen, auf die Sie Zugriff haben, ordnen Sie die Datensatzreihenfolge neu, sodass Datensätze, auf die Sie zugreifen können, zuerst zurückgegeben werden. Hinweis: Ungewöhnlich große Werte für sysparm_limit können die Systemleistung beeinträchtigen. Datentyp: Zahl Standard: 10.000 |
| sysparm_fields | Kommagetrennte Liste mit Feldern, die in der Antwort zurückgegeben werden sollen. Datentyp: Zeichenfolge |
| sysparm_input_display_value | Kennzeichnung, die angibt, ob Feldwerte unter Verwendung des Anzeigewertes oder des tatsächlichen Wertes festgelegt werden sollen. Abhängig von den verschiedenen Feldtypen kann der Endpunkt die übergebenen Anzeigewerte modifizieren, damit in der Datenbank die richtigen Werte gespeichert werden. Wenn Sie beispielsweise den Anzeigenamen für ein Referenzfeld senden, speichert der Endpunkt die sys_id für diesen Wert in der Datenbank. Wenn dieser Parameter bei Datums- und Uhrzeitfeldern auf „true“ gesetzt ist, wird der Datums- und Uhrzeitwert an die Zeitzone des aktuellen Benutzers angepasst. Bei „false“ werden der Datums- und Uhrzeitwert mit der GMT-Zeitzone eingefügt. Gültige Werte:
Datentyp: Boolesch Standard: false – Entspricht dem Datentyp, der während des Datenabrufs (GET-Methoden) zurückgegeben wird, d. h. die tatsächlichen Werte. Hinweis: Um den Wert eines verschlüsselten Felds festzulegen, müssen Sie diesen Parameter festlegen auf true. Wenn dieser Parameter nicht auf „true“ festgelegt ist, werden an verschlüsselte Felder übergebene Werte nicht gespeichert. Darüber hinaus muss der anfragende Benutzer vor dem Senden der Anforderung über den entsprechenden Verschlüsselungskontext verfügen. Verschlüsselte Felder werden für Benutzer ohne den entsprechenden Verschlüsselungskontext ausgeblendet. Weitere Informationen zur Feldverschlüsselung finden Sie unter Verschlüsselungsunterstützung. |
| sysparm_offset | Startdatensatzindex, für den der Datensatz abgerufen werden soll. Verwenden Sie diesen Wert, um den Datensatzabruf zu paginieren. Diese Funktion ermöglicht das Abrufen aller Datensätze in kleinen, verwaltbaren Abschnitten, unabhängig von der Anzahl der Datensätze. Wenn zum Beispiel dieser Endpunkt zum ersten Mal aufgerufen wird, ist sysparm_offset auf „0“ eingestellt. Verwenden Sie Datentyp: Zahl Standard: 0 |
| sysparm_query | Codierte Abfrage, die zum Filtern der Ergebnismenge verwendet wird. Sie können einen UI-Filter verwenden, um eine ordnungsgemäß codierte Abfrage zu erhalten. Syntax: sysparm_query=<col_name><operator><value>.
Bei allen Parametern wird zwischen Groß- und Kleinschreibung unterschieden. Abfragen können mehr als einen Eintrag enthalten, beispielsweise sysparm_query=<col_name><operator><value>[<operator><col_name><operator><value>]. Beispiel:
Codierte Abfragen unterstützen auch die Funktion „Sortieren nach“. Verwenden Sie die Klauseln Syntax:
Beispiel: Diese Abfrage filtert alle aktiven Datensätze und sortiert die Ergebnisse in aufsteigender Reihenfolge nach Nummer und dann in absteigender Reihenfolge nach Kategorie. Wenn ein Teil der Abfrage ungültig ist, z. B. durch Angabe eines ungültigen Feldnamens, ignoriert die Instanz den ungültigen Teil. Es werden dann nur Zeilen unter Verwendung des gültigen Teils der Abfrage zurückgegeben. Sie können dieses Verhalten mithilfe der Eigenschaft glide.invalid_query.returns_no_rows steuern. Legen Sie diese Eigenschaft auf „true“ fest, um bei einer ungültigen Abfrage keine Zeilen zurückzugeben. Hinweis: Diese Eigenschaft glide.invalid_query.returns_no_rows steuert das Verhalten aller Abfragen in der Instanz, beispielsweise in Listen, Skripts (GlideRecord.query()) und Webservice-APIs. Datentyp: Zeichenfolge |
| sysparm_view | UI-Ansicht, für die die Daten gerendert werden sollen. Bestimmt die Felder, die in der Antwort zurückgegeben werden. Gültige Werte:
Wenn Sie auch den Parameter sysparm_fields angeben, hat dieser Vorrang. Datentyp: Zeichenfolge |
Dot-Walking in REST API-Anforderungen
Sie können Dot-Walking verwenden, wenn Sie die Parameter sysparm_query und sysparm_fields in Anforderungen an REST APIs angeben, die diese Parameter unterstützen.
Dot-Walking in „sysparm_query“
Durch Dot-Walking im Parameter sysparm_query können Sie Abfragen mit zugehörigen Datensatzwerten filtern. Sie können beispielsweise alle Incident-Datensätze abrufen, in denen der Incident Unternehmen einen bestimmten Aktiensymbol-Wert hat.
https://<Instanz>.service-now.com/api/now/table/incident?sysparm_query=company.stock_symbol=NYX
Dot-Walking in „sysparm_fields“
Durch Dot-Walking im Parameter sysparm_fields können Sie Feldwerte aus mehreren Tabellen anzeigen. Zum Beispiel können Sie den Namen, die Sys_id und die Abteilung von jedem Benutzer abrufen, der bestimmte Rollen sowie die Rolle Name hat.
Die Anforderung wird in der Tabelle „Benutzerrollen“ [sys_user_has_role] ausgeführt, in der eine Viele-zu-Viele-Beziehung zwischen Benutzern und Rollen definiert wird. Die Antwort enthält Feldwerte aus den Tabellen „Benutzer“ [sys_user] und „Rollen“ [sys_user_role].
https://<Instanz>.service-now.com/api/now/table/sys_user_has_role?sysparm_fields=role%2Crole.name%2Cuser%2Cuser.name%2Cuser.sys_id%2Cuser.department&sysparm_query=role%3D3d43716d0f6002003a2d47bce1050e0d%5EORrole%3Dac73b52d0f6002003a2d47bce1050eec&sysparm_display_value=true
{
"result": [
{
"user.name": "Fred Johnson",
"user.sys_id": "f5a3716d0f6002003a2d47bce1050ed4",
"role.name": "support",
"user.department": {
"display_value": "Accounting",
"link": "https://<instance>.service-now.com/api/now/table/cmn_department/5b3b13530f58c2003a2d47bce1050e96"
},
"role": {
"display_value": "support",
"link": "https://<instance>.service-now.com/api/now/table/sys_user_role/3d43716d0f6002003a2d47bce1050e0d"
},
"user": {
"display_value": "Fred Johnson",
"link": "https://<instance>.service-now.com/api/now/table/sys_user/f5a3716d0f6002003a2d47bce1050ed4"
}
},
{
"user.name": "Fred Johnson",
"user.sys_id": "f5a3716d0f6002003a2d47bce1050ed4",
"role.name": "asset_mgmt",
"user.department": {
"display_value": "Accounting",
"link": "https://<instance>.service-now.com/api/now/table/cmn_department/5b3b13530f58c2003a2d47bce1050e96"
},
"role": {
"display_value": "asset_mgmt",
"link": "https://<instance>.service-now.com/api/now/table/sys_user_role/ac73b52d0f6002003a2d47bce1050eec"
},
"user": {
"display_value": "Fred Johnson",
"link": "https://<instance>.service-now.com/api/now/table/sys_user/f5a3716d0f6002003a2d47bce1050ed4"
}
}
]
}REST API-HTTP-Antwortcodes
Aufrufe an REST-Endpunkte geben HTTP-Antwortcodes zurück. Sie können diese Antwortcodes verwenden, um sicherzustellen, dass die REST API ordnungsgemäß ausgeführt wurde. Ist dies nicht der Fall, gibt der Endpunkt einen Fehlerantwortcode zurück. Verwenden Sie die Informationen in der Fehlerantwort, um Probleme mit Ihrem Aufrufformat zu beheben. Eine Liste der Standardantwortcodes, die ein Endpunkt zurückgeben kann, finden Sie unter REST API-HTTP-Antwortcodes. Die Liste der Antwortcodes, die von einer bestimmten ServiceNow REST API zurückgegeben werden, finden Sie in der REST API-Referenz.
REST API-Sicherheit
Standardmäßig verwenden ServiceNow-REST APIs die Standardauthentifizierung oder OAuth, um den Benutzerzugriff auf REST APIs/Endpunkte zu autorisieren. Sie können Ihre Instanz auch so konfigurieren, dass für den Zugriff auf REST APIs die Multi-Faktor-Authentifizierung verwendet wird.
Die in einem REST-Endpunkt angegebene Benutzer-ID unterliegt derselben Zugriffskontrolle wie ein interaktiver Benutzer. Jede Anforderung erfordert die richtigen Authentifizierungsinformationen wie Benutzername und Passwort. Stellen Sie sicher, dass jede Endpunktanforderung einen Autorisierungsheader mit zulässigen Anmeldeinformationen für den Zugriff auf den Endpunkt enthält.
ServiceNow-REST APIs unterstützen außerdem Cookies zur Bindung an die bestehende Sitzung.
Anleitungen zur Verwendung des Zertifikats zum Aufrufen der API und Informationen zur gegenseitigen Authentifizierung finden Sie unter Zertifikatsbasierte Authentifizierung.
Um den API-Bereich mithilfe von REST API-Zugriffsrichtlinien mit Filterkriterien wie IP, Rolle und Gruppe zu beschränken, können Sie REST API Auth Scope verwenden. Weitere Informationen zur REST API-Zugriffsrichtlinie finden Sie unter REST API-Zugriffsrichtlinien.
Sie können eine einzelne Richtlinie erstellen, um die eingehende Anforderung auf einer globalen REST API-Ebene zu blockieren, indem Sie die REST API-Zugriffsrichtlinie von außerhalb des vertrauenswürdigen Netzwerks auf einer REST-Standardauthentifizierungsebene verwenden.
Rollen für REST APIs
Neben der Anwenderauthentifizierung kann jeder REST-Endpunkt unterschiedliche Anforderungen für die Rollen haben, die für den Zugriff auf den Endpunkt erforderlich sind. Einige erfordern die Administratorrolle, andere API-spezifische Rollen. Rollenanforderungen sind in der Zugriffssteuerungsliste (ACL) angegeben, die der REST API/dem Endpunkt zugeordnet ist. Einzelheiten zu den gültigen Rollen für die einzelnen REST APIs/Endpunkte finden Sie in der REST API-Referenz. Sie können auch die zugehörige ACL für die API/den Endpunkt innerhalb einer Instanz über System Security > Zugriffssteuerung (ACL) suchen.
REST API-ACLs
REST API-ACLs definieren Kriterien, z. B. die erforderlichen Rollen und Bedingungen, die ein Benutzer erfüllen muss, um auf eine REST API oder einen Endpunkt von ServiceNow zuzugreifen. Eine einzelne ACL kann für eine gesamte REST API definiert werden, z. B. für die ACLs der Tabellen-API und der Anhang-API, oder für einen einzelnen Endpunkt, z. B. die ACL „clotho_rest_put“, die nur für PUT-Methoden von MetricBase gilt.
Die folgenden ACLs für ServiceNow-REST APIs sind im Basissystem verfügbar, aber standardmäßig deaktiviert. Alle anderen ACLs für ServiceNow-REST APIs sind standardmäßig aktiv.
- Tabellen-API
- Aggregieren-API
- Importsatz-API
- Anhang-API
Weitere Informationen zu ACLs finden Sie unter Regeln der Zugriffssteuerungsliste.
Zugriff auf REST API-Tabellen
Auf alle Tabellen, einschließlich Basissystemtabellen, globale Tabellen und Bereichstabellen, kann standardmäßig über Webservices zugegriffen werden. Um über Webservices auf Tabellen zuzugreifen, müssen Sie alle Sicherheitsanforderungen für Webservices erfüllen, z. B. Standardauthentifizierung und ACLs. Felder, für die die aufrufende Entität aufgrund von ACLs keine Rechte hat, werden in einer REST-Abfrageantwort nicht zurückgegeben.
Um den Zugriff auf Tabellen ohne Authentifizierung und Autorisierung zu ermöglichen, fügen Sie den Tabellennamen der Tabelle „Öffentliche Seiten“ [sys_public] mit dem Status Aktiv hinzu. Die REST-Schnittstelle erzwingt für zugeordnete Tabellen dennoch definierte ACLs. Wenn die ACL-Erzwingung nicht das gewünschte Verhalten ist, müssen Sie die ACLs für die Tabellen deaktivieren. Es wird jedoch nicht empfohlen, Ihre APIs öffentlich zu machen, da dies den öffentlichen Zugriff zum Aktualisieren von Daten in der Instanz ermöglicht.
Mithilfe des Kontrollkästchens Webservice-Interaktionen zulassen in den Zugriffseinstellungen der Tabellenanwendung können Sie außerdem den direkten Webservice-Zugriff auf Tabellen steuern. Dieses Kontrollkästchen muss aktiviert sein, um die Webservice-Interaktion mit der Tabelle zu ermöglichen.
Multi-Faktor-Authentifizierung für eingehenden REST
Wenn die Multi-Faktor-Authentifizierung für einen Benutzeraccount aktiviert ist, müssen Sie ein MFA-Token mit Anmeldeinformationen für Basic Authentication übermitteln, wenn Sie als dieser Benutzer REST-Anforderungen stellen.
Um ein MFA-Token mit einer REST-Anforderung zu senden, hängen Sie das Token an das Ende des Benutzerpassworts in der Zeichenfolge für die grundlegende Authentifizierung „username:password“ an, wie z. B. joe.employee:password62161147. Kodieren Sie die vollständige Zeichenfolge einschließlich des MFA-Tokens mit der Base64-Kodierung, und senden Sie dann die kodierte Zeichenfolge im Autorisierungsheader.
REST-Antworten für Multi-Faktor-Authentifizierung
Die Antwort auf eine MFA-Authentifizierungsanforderung hängt von der Gültigkeit der angegebenen Anmeldeinformationen und des MFA-Token ab.
| Ergebnis | Beschreibung |
|---|---|
| Die Anmeldeinformationen für Basic Authentication und das MFA-Token sind gültig | Der Benutzer wird authentifiziert, und die Sitzung wird erstellt. Die Anforderung wird normal verarbeitet. |
| Die Anmeldeinformationen für Basic Authentication sind gültig, aber das MFA-Token ist ungültig oder fehlt | Die Antwort gibt Fehler 401 zurück. Die Antwort enthält die Header „X-MFA_TOKEN“ mit dem Wert invalid. |
| Die Anmeldeinformationen für Basic Authentication sind ungültig | Die Antwort gibt Fehler 401 zurück. Der Header „X-MFA_TOKEN“ ist nicht in der Antwort enthalten. |
CORS-Unterstützung für REST APIs
Die REST API unterstützt die CORS-Sicherheit (Cross-Origin Resource Sharing). Mit der CORS-Unterstützung können Sie definieren, welche Domänen auf die einzelnen REST APIs zugreifen können. Durch das Definieren einer CORS-Regel für eine Domäne können Sie ursprungsübergreifende Anforderungen von dieser Domäne zulassen. Ursprungsübergreifende Anforderungen können nicht aus Domänen ohne eine CORS-Regel gestellt werden.
Sie können CORS so konfigurieren, dass nur bestimmte APIs/Endpunkte, HTTP-Methoden und Header von anderen Domänen zugänglich sind. Sie können beispielsweise Anforderungen an die Tabellen-API von einer bestimmten Domäne einschränken, um nur GET-Vorgänge zuzulassen.
Um die in Ihrer Instanz definierten CORS-Regeln anzuzeigen, navigieren Sie zu .
Sie können die CORS-Unterstützung für eine Instanz durch Setzen der Eigenschaft glide.rest.cors.enabled auf false deaktivieren. Wenn auf false gesetzt, wird für eingehende REST-Anforderungen keine CORS-Bewertung durchgeführt. Diese Eigenschaft ist standardmäßig true.
REST API Explorer
Der REST-API-Explorer ist ein ServiceNow-Tool, das Ihnen mithilfe von Informationen aus Ihrer Instanz eine Liste mit Endpunkten, Methoden und Variablen bereitstellt, die Sie zum Erstellen und Senden von REST-Anforderungen verwenden können.
Nachdem Sie die Anforderung erstellt haben, stellt der REST-API-Explorer Codebeispiele in mehreren Programmiersprachen, die Sie zum Initiieren der Anforderung verwenden können, sowie detaillierte Anforderungs- und Antwortinformationen bereit.
Um auf den REST-API-Explorer zuzugreifen, navigieren Sie in Ihrer Instanz zu . Sie müssen über die Rolle „rest_api_explorer“ verfügen, um auf den REST-API-Explorer zugreifen zu können. Weitere Informationen finden Sie unter REST-API-Explorer verwenden.
Unterstützung von Automated Test Framework
Das Automated Test Framework unterstützt eingehende REST-Testschritte. Sie können automatisierte Tests für benutzerdefinierte eingehende REST APIs einrichten, die Sie erstellen. Das Erstellen von Tests für Ihre benutzerdefinierten REST APIs vereinfacht das Testen von Upgrades und ermöglicht die Überprüfung, ob Änderungen an einer REST API abwärtskompatibel sind.
Beispiel-REST API-Client-Anwendungen
Es sind mehrere Beispiel-REST API-Client-Anwendungen und Quellcode verfügbar, um die Integrationen mithilfe von REST-Webservices zu demonstrieren. Die Beispiel-REST-Client-Anwendungen veranschaulichen die Verwendung der ServiceNow-REST API mit einer externen Anwendung, beispielsweise einer NodeJS- oder iOS-Anwendung.
Die Beispiele sind Open Source und stehen der Community zur Verfügung. Sie können diese Beispielanwendungen verwenden, um sich mit der REST-Funktionalität vertraut zu machen, oder sie als Ausgangspunkt zum Erstellen eigener REST-Client-Anwendungen verwenden.
Benutzer mit der Rolle „rest_api_explorer“ können auf die Liste der verfügbaren Clientanwendungen zugreifen, indem sie zu navigieren .
Klicken Sie beim Anzeigen der Liste der Anwendungen auf eine Anwendung, um den auf GitHub gehosteten Quellcode und zusätzliche Dokumentation anzuzeigen.
Entwicklerschulungen
Auf der ServiceNow® Developer Site erhalten Sie Schulungen für eingehende REST-Integrationen und ausgehende REST-Integrationen.
Zusätzliche Informationen
Der Rest des Abschnitts „REST APIs“ enthält Anleitungsthemen, die bestimmte Implementierungen mit der ServiceNow-REST API beschreiben, und enthält Referenzinformationen, die verschiedene Datenelemente beschreiben, die von der ServiceNow-REST API verwendet werden.