Ist es besser, wenn man eine REST-API auf einer subdomain oder in einem Unterordner?

Wir haben eine Webanwendung, die gehostet wird mit der URL http://example.com. Jetzt wollen wir erweitern ein Teil dieser Anwendung als Rest-Dienst, und wir debattieren über die beste URL-Muster. Ich habe gesucht, aber konnte keine konkrete Anleitung.

Sollten wir die URL mit dem Muster http://api.example.com oder http://exaple.com/api/v1?

Gibt es eine standard-Anleitung für dies?

  • Gibt es keine Erfahrung auf andere Vermögenswerte des Unternehmens, oder irgendwo sonst in der Entwicklung der Mannschaft? Entweder Wahl würde nur gut funktionieren.
  • Beides sieht gut aus, In einem von unserem Projekt entschieden wir uns für api.XXXXX.com format
  • Auch wir hatten die gleiche Diskussion bei der Arbeit, gingen wir mit api.xxxx.com. Dieser Ansatz schien ordentlicher. Wir haben verschiedene set-up für die API-Cluster jetzt.
  • Es gibt einen wichtigen Unterschied - api.example.com möchte hinzufügen, CORS-Anfragen, in der Erwägung, dass example.com/api nicht.
InformationsquelleAutor Abhijith Prabhakar | 2013-01-28
  1. 12

    Es hängt von Ihren Bedürfnissen ab.

    Wenn Sie http://api.example.com es macht die API subdomain. Im Grunde, dieses URL-Muster ist gut, wenn der REST-service konsumiert werden, die von mehreren Kunden, aber wenn nur ein client verbunden ist, um Ihre API dann das Muster http://example.com/api/v1 ist gut. Jedoch, wenn Sie hinzufügen möchten mehr API mit mehr clients mit ihm verbunden, es ist besser http://example.com/api/v1. Betrachten Sie beispielsweise die folgenden.

    http://example.com/reportapi/apioperation?parameters

http://example.com/paymentapi/apioperation?parameters

http://example.com/searchapi/apioperation?parameters

    Nicht zuletzt, PayPal verwendet das Muster http://example.com/api/v1.

    • Paypal-APIs sind ein bisschen alt. Streifen ist mit api.stripe.com. Auch SO verwendet api.stackoverflow.com.
    • Paypal nicht verwenden dieses Muster. Paypal verwendet https://api.[sandbox].paypal.com/v1/ Muster
    InformationsquelleAutor Jobert Enamno
  2. 2

    Ich denke, Sie sollten weder http://api.example.com noch http://example.com/api/v1.

    Stattdessen würde ich vorschlagen, mit http://example.com/api - und content-negotiation für die Versionsverwaltung.

    Hier sind meine Gedanken, warum:

    Mit einer subdomain:

    Pro die URI-Schema-Spezifikation, Sie bei der Definition der API in der Behörde Teil der URI, die verwendet wird, um zu definieren, Ihre Gastgeber, eher als die Definition einer Anwendung oder API auf Ihrem Rechner. Erstellen Sie in Wirklichkeit eine andere Adresse für Ihre API, was bedeutet, dass die Authentifizierung funktioniert möglicherweise nicht für api.example.com da es für example.com.

    Einen triftigen Grund, dies zu tun wäre, wenn Sie entwerfen eine neue Instanz für mobile Geräte, z.B. mobile.example.com aber ich hielte diese mehr eine infrastrukturelle Entscheidung und nicht um eine funktionelle eine.

    Über eine nicht-versionierte Pfad auf die Haupt-domain:

    Gibt es zwei bits von Informationen hier: einer ist ein Indiz dafür, dass es eine API-Ressource und der zweite ist, dass es die Versionsnummer der API-Ressource (v1).

    Gibt es nichts schlecht über die Verwendung von /api/ um eine Unterscheidung zwischen den API-und, zum Beispiel, Ihre web-anzeigen, die möglicherweise die Ausführung unter /web/. Diese können als gemeinsame best practice.

    Ich bin mir nicht sicher, ob du das beabsichtigt, aber deine Frage enthält eine Abfrage auf, wie zu lösen API-Versionierung. Ich persönlich denke, dass API-Versionierung sollte nicht getan werden mit URLs, wie Sie gedacht sind, stabil zu bleiben, so lange wie möglich. Coole URIs ändern sich nicht! Erwägen Sie stattdessen, die Verwendung von HTTP-Content-Type-information zur version der API. Ich fand diese Methode in Der VMware-Dokumentation. Zusätzlich ist hier eine ziemlich alte, aber immer noch nützlich, post über Inhalt, Art Versionierung von Peter Williams.

    • Ich möchte gern die version in der url folgt das "Cool URIs don 'T change" viel besser als die Verwendung des Content-Type für die version. Warum? Angenommen, Sie ändern den Namen Ihres Benutzer-Modell zu person in einer zukünftigen Version, so dass Sie nur umleiten Benutzer zu den Menschen. Dann, zu einem späteren Zeitpunkt entscheiden Sie hinzufügen, um ein neues Modell mit dem Namen Benutzer. Jetzt sind Sie gezwungen, um zu ändern der url. Stattdessen werden Sie verwendet haben konnten, die Versionierung in der url von Anfang an. 100 releases später, wenn Sie Ihre v1-api zu arbeiten, dann alle v1-links funktionieren genau das gleiche. Einfach. (plus-urls sind meistens einfacher zu ändern, dann Header)
    • Ich natürlich nicht einverstanden mit dieser Antwort. Ben ' s Kommentar irgendwie bekommt es, aber es ist nicht ganz klar. Das wichtigste zum mitnehmen ist, dass jemand, der Grundlagen Ihrer Anwendung die Funktionalität auf die API -, Sie brauchen eine Garantie, dass Ihr API ist immer zu akzeptieren, was Sie geben und was Sie erwarten von ihm. Wenn Sie nicht version Ihrer URLs, die dann eine bestimmte URL wird unweigerlich anfangen zu treiben, um so Ihre interne Implementierung reift und sich verändert.
    • Stimme nicht 100%. Authentifizierung kann auf allen subdomains, wenn nötig, aber trotzdem, Sie in der Regel don T wollen die gleichen auth für Ihre API (zB. API-keys). Darüber hinaus werden die HTTP-Content-Type-Lösung ist unnötig kompliziert, und der verschiedenen API-Versionen wird es wohl nicht sein mit den gleichen urls. Sie werden am Ende in gemeinsamer urls, und einige bestimmte andere... das Chaos dann perfekt :/
    InformationsquelleAutor brazo
  3. 0

    Dies ist ein Fall, der Kompromisse, keine einzige beste Lösung.

    Zum Beispiel, wenn Ihr http://example.com/ bietet Inhalte, die über einen standard-web-Oberfläche sowie über die API, dann müssen Sie so etwas wie http://api.example.com/api/<version>/<the usual resource pattern>
    nur zu separaten browser-basierte Anwendung, die den Zugriff aus der API-Interaktion. Macht das Sinn?

    Beispiel: api.rottentomatoes.com

    Jedoch, selbst wenn Ihre domain ist speziell für API-Aufrufe, ist es sinnvoll, die oben genannten Muster sowieso, und behalten uns http://example.com/ für andere Möglichkeiten der Interaktion mit Ihrer Anwendung. Zum Beispiel, möchten Sie vielleicht http://example.com/mobile/, etc.

    InformationsquelleAutor TheWhiteRabbit
Schreibe einen Kommentar