1. Einführung

1. Einführung

Andere Anwendungen als das Web-Browsing verwenden häufig HTTP [HTTP] als Substrat, eine Praxis, die manchmal als Erstellung von "HTTP-basierten APIs", "REST-APIs" oder einfach "HTTP-APIs" bezeichnet wird. Dies geschieht aus verschiedenen Gründen, darunter:

• Vertrautheit bei Implementierern, Spezifizierern, Administratoren, Entwicklern und Benutzern;

• Verfügbarkeit einer Vielzahl von Client-, Server- und Proxy-Implementierungen;

• Benutzerfreundlichkeit;

• Verfügbarkeit von Webbrowsern;

• Wiederverwendung bestehender Mechanismen wie Authentifizierung und Verschlüsselung;

• Vorhandensein von HTTP-Servern und -Clients in Zielbereitstellungen; und

• seine Fähigkeit, Firewalls zu durchqueren.

Diese Protokolle sind oft ad hoc, nur für die Bereitstellung durch einen oder wenige Server und den Verbrauch durch eine begrenzte Anzahl von Clients vorgesehen. Infolgedessen ist ein Korpus von Praktiken und Werkzeugen zur Definition HTTP-basierter APIs entstanden, die diese Bedingungen begünstigen.

Wenn jedoch eine solche Anwendung mehrere separate Implementierungen hat, auf mehreren unkoordinierten Servern bereitgestellt wird und von verschiedenen Clients genutzt wird (wie es oft bei HTTP-APIs der Fall ist, die durch Standardisierungsbemühungen definiert werden), können für begrenzte Bereitstellungen vorgesehene Werkzeuge und Praktiken ungeeignet werden.

Diese Diskrepanz ist weitgehend darauf zurückzuführen, dass die Clients und Server der API mit unterschiedlichen Geschwindigkeiten implementieren und sich entwickeln werden, was dazu führt, dass Bereitstellungen mit unterschiedlichen Funktionen und Versionen koexistieren müssen. Infolgedessen müssen die Designer HTTP-basierter APIs, die für solche Bereitstellungen vorgesehen sind, sorgfältiger überlegen, wie die Erweiterbarkeit des Dienstes gehandhabt wird und wie unterschiedliche Bereitstellungsanforderungen berücksichtigt werden.

Allgemeiner gesagt steht ein Anwendungsprotokoll, das HTTP verwendet, vor einer Reihe von Designentscheidungen, darunter:

• Sollte es ein neues URI-Schema definieren? Neue Ports verwenden?

• Sollte es Standard-HTTP-Methoden und Statuscodes verwenden oder neue definieren?

• Wie kann der maximale Wert aus der Verwendung von HTTP extrahiert werden?

• Wie kann es mit anderen Verwendungen von HTTP koexistieren -- insbesondere Web-Browsing?

• Wie können Interoperabilitätsprobleme und "Protokoll-Sackgassen" vermieden werden?

Abschnitt 2 definiert, wann dieses Dokument gilt, Abschnitt 3 untersucht die Eigenschaften von HTTP, die wichtig zu erhalten sind, und Abschnitt 4 enthält Best Practices für die Spezifikation von Anwendungen, die HTTP verwenden.

Es wurde hauptsächlich geschrieben, um IETF-Bemühungen zur Definition von Anwendungsprotokollen unter Verwendung von HTTP für die Bereitstellung im Internet zu leiten, könnte aber in anderen Situationen anwendbar sein. Beachten Sie, dass die hierin enthaltenen Anforderungen nicht notwendigerweise für die Entwicklung generischer HTTP-Erweiterungen gelten.

Dieses Dokument macht [RFC3205] obsolet, um die Erfahrung und Entwicklungen bezüglich HTTP in der Zwischenzeit widerzuspiegeln.