In der spielen Integrationen eine Schlüsselrolle bei der Anwendungsgestaltung. Eine der wichtigsten Technologien hierfür ist die . Kenntnisse der REST-API sind eine wichtige Fähigkeit für jeden technischen Spezialisten. In diesem Artikel stellen wir Ihnen 25 REST-API-Fragen vor, die Ihnen dabei helfen, sich auf ein Vorstellungsgespräch vorzubereiten und Ihre Fähigkeiten zu verbessern. Viel Spaß beim Lesen! Softwareentwicklungsbranche REST-API Zunächst unterteilt der Interviewer die Fragen zur REST-API normalerweise in theoretische und praktische. Zuerst werden 2-3 theoretische Fragen zur Terminologie und zu HTTP-Anforderungsmethoden gestellt, und dann erhalten Sie eine praktische Aufgabe zum Erstellen einer Anforderung. Dieser Artikel enthält häufig gestellte theoretische Fragen und ich plane, im nächsten Artikel Beispiele für praktische Aufgaben im Zusammenhang mit REST API zu veröffentlichen. Wir wissen nicht im Voraus, welche Fragen Sie in einem Vorstellungsgespräch gestellt bekommen, aber ich bin sicher, dass Sie beim Durcharbeiten unserer Liste typischer Fragen wahrscheinlich tiefer in das Thema eintauchen und Ihr Wissen über REST API auf jeden Fall verbessern werden. Gehen wir nun vom Einfachen zum Komplexen vor, beginnend mit der grundlegenden Terminologie und fahren mit einem Abschnitt mit komplexeren Fragen fort. 1. Was ist REST? Antwort: Im Zusammenhang mit REST werden drei Begriffe verwendet, die oft als dasselbe angesehen werden, was jedoch nicht ganz stimmt. Diese Begriffe sind REST, REST API und RESTful API. Nun folgt eine Antwort zu REST. Der Begriff steht für Representational State Transfer und ist ein auf dem HTTP-Protokoll (Hypertext Transfer Protocol) basierender Architekturstil für die Entwicklung von Anwendungen, die über ein Frontend und/oder eine Integration mit externen Systemen verfügen. REST beschreibt Richtlinien, denen die zu entwickelnden API-Dienste folgen sollten. Diese Prinzipien stellen sicher, dass Anfragen zwischen Client und Server über HTTP übermittelt werden. 2. Was ist REST-API? Antwort: Eine API ist eine Programmierschnittstelle, die es einzelnen Anwendungen ermöglicht, miteinander zu kommunizieren und Daten auszutauschen. Eine App für Essenslieferungen kann beispielsweise die Google Maps API verwenden, um den Standort des Kuriers zu verfolgen und auf einer Karte anzuzeigen. Eine REST-API ist eine API, die den Prinzipien von REST folgt und alle Daten als Ressourcen behandelt, die jeweils durch einen eindeutigen Uniform Resource Identifier (URI) dargestellt werden. 3. Was ist eine RESTful API? Antwort: Eine RESTful API ist eine API, die nach den Regeln (oder man kann auch „Prinzipien“ sagen) von REST entwickelt wurde. Mit anderen Worten ist der Unterschied zwischen REST API und RESTful API terminologischer Natur. Im ersten Fall handelt es sich um einen Satz von REST-Regeln, im zweiten Fall um die Implementierung einer bestimmten API nach REST-Regeln. Der Begriff RESTful API wird oft der Kürze halber durch REST API oder sogar REST ersetzt. Wenn Systemanalytiker in einem Anwendungsdiagramm Pfeile mit der Aufschrift REST zeichnen, meinen sie eine RESTful API. 4. Was sind die beiden Hauptprinzipien von REST? Antwort: REST-API-Anfragen müssen zwei Grundprinzipien folgen: Trennung in Client und Server: Die Interaktion zwischen Client und Server erfolgt in Form von Anfragen und Antworten. Nur Clients können Anfragen stellen und nur Server können Antworten senden, um unabhängig voneinander zu arbeiten. Einheitliches Protokoll: Die Interaktion zwischen Client und Server muss über ein einziges Protokoll erfolgen. Bei REST ist dieses Protokoll HTTP. 5. Welche weiteren Prinzipien von REST kennen Sie? Antwort: Sie können mindestens 4 weitere Prinzipien nennen. REST-API-Anfragen speichern keinen Status auf dem Server und können durch Serverschichten laufen und zwischengespeichert werden. Sie können in der Serverantwort auch ausführbaren Code an Clients senden. Server Stateless: Der Server speichert keine Informationen über vergangene Anfragen/Antworten. Jede Anfrage und Antwort enthält alle Informationen, die zum Abschließen der Interaktion erforderlich sind. Stateless-Kommunikation reduziert die Serverlast, spart Speicher und verbessert die Leistung. Schichtsystem: Zwischen dem Client und dem API-Server sind zusätzliche Server in Form von Schichten möglich, um verschiedene Funktionen auszuführen. In einem auf REST-Prinzipien basierenden System sind Schichten modular und können hinzugefügt und entfernt werden, ohne die Kommunikation zwischen Client und Server zu beeinträchtigen. Cachefähigkeit: Die Antworten des Servers geben an, ob seine Ressource zwischengespeichert werden kann, sodass Clients jede Ressource zwischenspeichern können, um die Leistung zu verbessern. Code auf Anfrage: Der Server kann in seiner Antwort ausführbaren Code an Clients senden, um ihn innerhalb der Client-Anwendung auszuführen. 6. Was ist eine Ressource? Antwort: In REST wird jedes zugängliche Objekt auf der Serverseite als Ressource bezeichnet. Eine Ressource ist ein Objekt, das einen Typ, damit verbundene Daten, eine Beziehung zu anderen Ressourcen auf dem Server und eine Liste von Methoden hat, die zum Arbeiten damit verwendet werden können. Eine Ressource kann beispielsweise eine HTML- oder Textdatei, eine Datendatei, ein Bild oder Video oder eine ausführbare Codedatei sein. Eine Ressource wird durch einen Uniform Resource Identifier oder URI identifiziert. Clients greifen auf Ressourcen zu, indem sie ihre URIs in HTTP-Anfragen verwenden. 7. Was ist eine URL? Antwort: URI steht für Uniform Resource Identifier. Dies ist eine Zeichenfolge, die eine Ressource auf dem Server identifiziert. Jede Ressource hat ihre eigene eindeutige URI, die es Clients ermöglicht, auf diese Ressource zuzugreifen und Aktionen mit ihr auszuführen, wenn sie in eine HTTP-Anforderung aufgenommen wird. Der Vorgang, auf eine Ressource über ihre URI zu verweisen, wird als „Adressierung“ bezeichnet. 8. Was ist CRUD? Antwort: CRUD steht für „Create, Read, Update, Delete“. Dies sind die vier Hauptaktionen, die über die REST-API an Datenbanken ausgeführt werden können. Jede Aktion hat ihre eigene HTTP-Anforderungsmethode: Erstellen = POST Lesen = GET Aktualisieren = PUT Löschen = LÖSCHEN 9. Was ist mit der Nutzlast in der Serverantwort gemeint? Antwort: Die HTTP-Antwortnutzlast bezeichnet die Ressourcendaten, die vom Client angefordert wurden. Diese werden auch kurz „HTTP-Antwortnutzlast“ genannt. Diese Daten können in den Formaten JSON, XML, HTML, Bilder, Dateien usw. vorliegen, je nachdem, was der Server genau bereitstellt. 10. Was ist REST-Messaging? Antwort: Messaging in REST bezieht sich auf den Nachrichtenaustausch zwischen Client und Server. Die Kommunikation beginnt immer damit, dass der Client eine HTTP-Anfrage an den Server stellt. Der Server verarbeitet diese Anfrage und sendet dann eine HTTP-Antwort zurück, die den Status der Anfrage und alle vom Client angeforderten Ressourcen angibt. 11. Was ist ein Nachrichtenbroker in REST? Antwort: Im Kontext von REST bezeichnet der Begriff „Message Broker“ eine Middleware, die dazu dient, Nachrichten zwischen verschiedenen Komponenten oder Systemen in einer verteilten Anwendung zu übermitteln. Der Broker kann asynchronen Datenaustausch, Message Queuing und Nachrichtenverarbeitung zwischen verschiedenen Systemmodulen bereitstellen. Mit Message Brokern können asynchrone Vorgänge verwaltet oder Benachrichtigungen gesendet werden. Der Message Broker ist kein natives REST-Element, da... REST sich auf die synchrone Kommunikation zwischen Client und Server über HTTP-Anfragen konzentriert. 12. Welche HTTP-Anforderungsmethoden werden von REST unterstützt? Antwort: Die HTTP-Anforderungsmethode gibt die gewünschte Aktion an, die der Server für die Ressource ausführen soll. In REST gibt es vier Hauptmethoden, um HTTP-Anforderungen von einem Client an einen Server zu stellen: GET: Fordert eine Ressource vom Server an, diese Methode ist schreibgeschützt. POST: Erstellt eine neue Ressource auf dem Server. PUT: Aktualisiert eine vorhandene Ressource auf dem Server. LÖSCHEN: Löscht eine Ressource vom Server. 13. Was ist der Unterschied zwischen den Methoden POST und PUT? Antwort: POST dient zum Erstellen einer Ressource auf dem Server, während PUT zum Ersetzen einer Ressource an einer bestimmten URI durch eine andere Ressource dient. Wenn Sie PUT auf eine URI anwenden, der bereits eine Ressource zugeordnet ist, wird diese durch PUT ersetzt. Falls an der angegebenen URI keine Ressource vorhanden ist, erstellt PUT eine. PUT ist idempotent, d. h. wenn es mehrmals aufgerufen wird, wird nur eine Ressource erstellt. Das liegt daran, dass bei jedem Aufruf eine vorhandene Ressource ersetzt wird (oder eine neue erstellt wird, wenn es nichts zu ersetzen gibt). POST ist nicht idempotent. Wenn Sie beispielsweise POST 10 Mal aufrufen, werden auf dem Server 10 unterschiedliche Ressourcen erstellt, jede mit ihrer eigenen URI. Obwohl es selten verwendet wird, können POST-Antworten zwischengespeichert werden, PUT-Antworten jedoch nicht. POST-Anfragen gelten im Allgemeinen als nicht zwischenspeicherbar, können aber zwischengespeichert werden, wenn sie eindeutige Informationen zur „Aktualität“ der Daten enthalten. Eine ausführlichere Antwort ist, dass die Antwort auf eine POST- (oder PATCH-)Anforderung zwischengespeichert werden kann, wenn die Daten „frisch“ sind und der Content-Location-Header (en-US) gesetzt ist. Dies wird jedoch selten implementiert. Daher sollte das Zwischenspeichern von POST nach Möglichkeit vermieden werden. 14. Was sind die Hauptteile einer HTTP-Anfrage? Antwort: In REST gibt es die folgenden grundlegenden Komponenten einer HTTP-Anforderung: Die Anforderungsmethode, die an die Ressource gesendet wird (also GET, POST, PUT, DELETE). Eine URI, die die angeforderte Ressource auf dem Server identifiziert. HTTP-Version – also welche Version in der Serverantwort enthalten sein soll. Der HTTP-Anforderungsheader enthält Metadaten zur Anforderung, wie etwa den Benutzeragenten, vom Client akzeptierte Dateiformate, Anforderungstextformat, Sprache, Caching-Einstellungen usw. Der Text einer HTTP-Anforderung enthält alle mit der Anforderung verknüpften Daten. Dies ist nur erforderlich, wenn die Anforderung Daten auf dem Server mithilfe der Methoden POST oder PUT ändern soll. 15. Was sind die Hauptteile einer HTTP-Antwort? Antwort: HTTP-Antworten werden vom Server an den Client gesendet. Sie informieren den Client darüber, dass die angeforderte Aktion abgeschlossen wurde (oder nicht) und über die Bereitstellung aller angeforderten Ressourcen. Eine HTTP-Antwort besteht aus vier Hauptkomponenten: Verwendete HTTP-Version. Statusleiste mit Anforderungsstatus und HTTP-Antwortstatuscode. HTTP-Antwortheader mit Metadaten zur Antwort, einschließlich Zeit, Servername, Benutzeragent, zurückgegebene Ressourcendateiformate, Caching-Informationen. HTTP-Antworttext mit Daten über die vom Client angeforderte Ressource. 16. Nennen Sie mindestens 3 Codes für erfolgreiche HTTP-Server-Antworten Antwort: Der Server gibt die folgenden Vorgangsstatuscodes zurück, wenn die Anforderung erfolgreich verarbeitet wurde: 200 OK: Die Anfrage wurde erfolgreich abgeschlossen. 201 Erstellt: Die Anforderung war erfolgreich und die Ressource wurde erstellt. 202 Akzeptiert: Dieser Status bedeutet, dass der Server die Anfrage des Clients akzeptiert, die Verarbeitung jedoch noch nicht abgeschlossen hat. Die Verarbeitung kann asynchron erfolgen. 17. Nennen Sie bei der Weiterleitung einer Anfrage mindestens 4 Server-HTTP-Antwortcodes Antwort: Der Server gibt bei der Umleitung einer Anfrage folgende Statuscodes zurück: 301 Dauerhaft verschoben: Dieser Status teilt dem Client mit, dass die angeforderte Ressource dauerhaft zu einer anderen URL verschoben wurde und der Client auf die neue URL zugreifen muss, um auf die Ressource zuzugreifen. 302 Gefunden: Dieser Status zeigt an, dass die Ressource vorübergehend zu einer anderen URL verschoben wurde und der Client vorübergehend die neue URL verwenden sollte. 307 Temporäre Weiterleitung: Ähnlich wie 302, aber der Client muss beim Zugriff auf die neue URL dieselbe Anforderungsmethode verwenden. 308 Permanente Weiterleitung: Ähnlich wie 301, aber der Client muss beim Zugriff auf die neue URL dieselbe Anforderungsmethode verwenden 18. Nennen Sie mindestens 4 Codes für erfolglose HTTP-Server-Antworten. Antwort: Der Server gibt die folgenden Codes zurück, wenn die Anfrage nicht erfolgreich ist: 400 Ungültige Anfrage: Die Anfrage wurde aufgrund eines Fehlers in der Anfrage, beispielsweise eines Tippfehlers oder fehlender Daten, nicht abgeschlossen. 401 Nicht autorisiert: Die Anforderung wurde nicht abgeschlossen, da der Client nicht authentifiziert ist oder keine Berechtigung zum Zugriff auf die angeforderte Ressource hat. 403 Verboten: Die Anforderung wurde nicht abgeschlossen, da der Client authentifiziert, aber nicht zum Zugriff auf die angeforderte Ressource berechtigt ist. 404 Nicht gefunden: Die Anforderung wurde nicht abgeschlossen, da der Server die angeforderte Ressource nicht finden konnte. 19. Nennen Sie mindestens 3 Server-Fehlercodes. Antwort: Der Server gibt die folgenden Codes zurück, wenn auf dem Server ein Fehler auftritt: 500 Interner Serverfehler: Die Anforderung wurde aufgrund eines unerwarteten Problems mit dem Server nicht abgeschlossen. 502 Bad Gateway: Die Anforderung wurde aufgrund einer falschen Antwort vom Upstream-Server nicht abgeschlossen. 503 Service nicht verfügbar: Der Server konnte die Anfrage aufgrund von Wartungsarbeiten, Überlastung oder anderen vorübergehenden Störungen nicht verarbeiten. Eine Liste der gebräuchlichsten HTTP-Codes finden Sie hier 20. Was ist der Unterschied zwischen REST und GraphQL Antwort: GraphQL ist eine Abfragesprache, die es Clients ermöglicht, nur die Daten abzufragen, die sie benötigen. In GraphQL definiert der Client die Struktur und das Format der Daten, die er empfangen möchte, und der Server gibt sie entsprechend dieser Anfrage zurück. Der Hauptunterschied besteht darin, dass REST für jede Ressource ein festes Anfrage- und Antwortformat hat, während GraphQL es Clients ermöglicht, ihre Anfrage zu definieren und nur die Informationen abzurufen, die sie benötigen, was die Verwendung effizienter und flexibler macht. 21. Was ist der Unterschied zwischen REST und SOAP? Antwort: REST und SOAP (Simple Object Access Protocol) sind zwei Ansätze zum Erstellen von APIs. Es gibt drei Hauptunterschiede zwischen ihnen: SOAP ist ein striktes Protokoll zum Erstellen sicherer APIs. REST ist kein Protokoll, sondern ein Architekturstil, der durch eine Reihe von Richtlinien, den sogenannten REST-Prinzipien, vorgegeben wird. - REST-APIs sind einfacher zu erstellen, leichter und im Allgemeinen schneller als SOAP-APIs. SOAP-APIs gelten als sicherer als REST-APIs, obwohl in REST-APIs dennoch Sicherheitsfunktionen implementiert werden können, die sie relativ sicher machen. – REST ermöglicht das Zwischenspeichern von Antworten, SOAP hingegen nicht. SOAP kodiert Daten im XML-Format. – REST ermöglicht Ihnen die Kodierung von Daten in jedem beliebigen Format, obwohl XML und JSON am gängigsten sind. 22. Was ist der Unterschied zwischen REST und AJAX? Antwort: Asynchrones JavaScript oder AJAX ist eine Reihe von Webentwicklungstechnologien, die in Webanwendungen verwendet werden. Im Kern ermöglicht AJAX einer Webseite, Anfragen an den Server zu stellen und die Benutzeroberfläche der Seite zu aktualisieren, ohne die gesamte Seite aktualisieren zu müssen. Ein AJAX-Client kann die REST-API in seinen Anfragen verwenden, aber AJAX muss nicht nur mit der REST-API funktionieren. REST-APIs können mit jedem Client kommunizieren, unabhängig davon, ob dieser AJAX verwendet oder nicht. Im Gegensatz zu REST, das HTTP-Anfragen und -Antworten zum Nachrichtenaustausch verwendet, sendet AJAX seine Anfragen mithilfe des in JavaScript integrierten XMLHttpRequest-Objekts an den Server. Serverantworten werden vom JavaScript-Code der Seite ausgeführt, um deren Inhalt zu ändern. 23. Was ist der „Contract First“-Ansatz zur REST-API-Entwicklung? Antwort: Der Contract First-Ansatz zur REST-API-Entwicklung ist eine Methode, bei der die API-Spezifikation und der Vertrag erstellt und definiert werden, bevor die eigentliche Entwicklung beginnt. Dieser Vertrag dient als wichtiges Dokument, das definiert, wie Clients mit der API interagieren können und welche erwarteten Ergebnisse aus verschiedenen Anfragen erzielt werden. 24. Was sind die Vorteile von Contract First? Antwort: Als Vorteile des Contract First-Ansatzes sind folgende zu nennen: Klare API-Definition: Die API-Spezifikation und der Vertrag definieren, wie die API mit Clients interagieren soll. Risiken reduzieren: Eine vorläufige Vertragsgenehmigung mit Kunden trägt dazu bei, das Risiko von Missverständnissen und der Nichterfüllung der Erwartungen an die API-Entwicklung zu reduzieren. Verbesserte Dokumentation: Der Vertragstext dient häufig als Dokumentation der API und erleichtert so die Nutzung und Integration. 25. Was ist der Code First-Ansatz zur REST-API-Entwicklung? Antwort: Der Code First-Ansatz zur REST-API-Entwicklung ist eine Methode, bei der zuerst die API-Funktionalität entwickelt und dann automatisch eine API-Spezifikation basierend auf dieser Funktionalität generiert wird. Das Kennzeichen des Code First-Ansatzes ist, dass sich Entwickler auf das Schreiben der API-Logik konzentrieren und Tools verwenden, mit denen sie automatisch Dokumentationen und Spezifikationen basierend auf dieser Logik erstellen können. Im Allgemeinen können beide Ansätze, Code First und Contract First, im selben API-Entwicklungsprojekt kombiniert werden. In diesem Fall wird Code First für Rapid Prototyping verwendet, gefolgt von Contract First zur Formalisierung des Vertrags. Ich hoffe, dieser Artikel ist für Sie bei der Vorbereitung auf ein Vorstellungsgespräch oder beim Auffrischen Ihrer Kenntnisse über REST API hilfreich.
