RESTful Web Application als Webseite und Schnittstelle

[Sam Bucca]

Moin Leute,

ich habe glaub ich ein kleines Verständnissproblem.

Über REST habe ich mich informiert. Die Technik der Clean URLs und der Ressourcen orientierung ist mir klar und ich kann sie auch mittels htaccess umsetzen.

Jetzt könnte ich natürlich (bsp. in PHP/JAVA/etc.) eine Page basteln, welche auf ein GET-Request reagiert und mir das ganze als Webseite ausgibt, damit Sie von Menschen konsumiert werden kann.

Wenn ich jetzt allerdings gerne möchte, dass auch Maschinen (bsp. eine App) zusätzlich auf die Daten zugreifen kann, dann muss die Ausgabe des GET-Requests (sprich der Response) ja anders aufgebaut sein. Dann muss dieser Response nicht mehr das ganze CSS und Design beinhalten sondern lediglich Daten (XML/JSON).

Im Prinzip beschreibt dies ja das MVC-Designkonzept. Allerdings bin ich mir nicht ganz sicher wie ich das anwenden soll.

Muss ich ein "Backend" erstellen, welches mir die Daten nach REST als JSON bereit stellt und ein Frontend, welches dann auf die Daten zugreift und diese mit CSS/Design für Menschen darstellt? Wie könnte so eine Struktur aussehen?

Für Input wäre ich sehr dankbar

 

[Umbel]

Wenn du es hübsch haben willst ... Ja dann baust du dir eine Oberfläche welche deinen eigenen REST-Service konsumiert. Du könntest natürlich auch Anhand es anfordenden Application-Type eine hübschere Form ausliefern. Aber das wiederspricht eigentlich der Idee eines Service.

 

[blablub1212]

Als Input würde ich mir einfach mal ein paar MVC-Frameworks angucken.

Für PHP:

- Symfony
- Laravel

Für JavaScript:

- SailsJS
- AngularJS

Im Prinzip läuft das immer gleich ab, du stellst eine Anfrage an dein Backend (z. B. getCustomerlist), das Backend anwortet dir in Form eines JSON-Arrays, die Antwort wird von einem Controller verarbeitet und dein View (z. B. HTML) rendert dir die Infos, so wie sie von Menschen gesehen werden sollen.

Die "Maschine" macht das gleiche beim einem API-Aufruf, das Antwort Array wird geparsed und über weitere Funktionen weiter verarbeitet.

 

[Sam Bucca]

Super, vielen Dank schon mal für eure Antworten.

Wie würde ich denn sinnvoller weise mein Backend vom Frontend trennen (unter Logik- und Sicherheitsaspekten)?

Um das mal zu verdeutlichen, macht so etwas sinn:

http(s)://www.meine-domaine.de/backend/resType/id

Dann würden die webseiten wie folgt aussehen:

http(s)://www.meine-domaine.de/resType/id

 

[Umbel]

Da musst du bitte kurz klären was du mit Backend meinst ... damit wir die gleichen Wörter für die gleichen Dinge verwenden

 

[Sam Bucca]

Bitte berichtigt mich, wenn ich begriffe falsch verwenden sollte!

In den obrigen Beitragen wurde mir gesagt, dass, um mein Ziel zu erreichen, eine Trennung von Service (der Teil, welcher die Daten als XML/JSON/etc. (also Mashinen lesbar) zurück gibt) und Frontend (Menschen lesbare aufbereitung der Daten aus dem Service).

Was ich als Backend bezeichnet habe ist der Teil, welcher die Maschinen lesbare Ausgabe tätigt.

Ich hoffe ich habe mich nicht noch schlechter ausgedrückt

 

[Umbel]

Ok ...

Ein Frontend ist normalerweise die Oberfläche die ein Nutzer sieht, ein Backend etwas z.B. derjenige sieht der die Daten / das System pflegt.

Im Idealfall sind deine Daten Menschen und Maschinenlesbar ... Datenstrukturen wie JSON und XML sie darstellen lassen sich auch von Menschen lesen.

Wenn du jetzt aber für den Menschen z.B. eine Tabelle darstellen willst, vlt sogar mit Sortierung dann solltest du einfach eine eigenständige Anwendung erstellen die deinen Service als API konsumiert.

 

[Sam Bucca]

Ich muss ja, um die API anderen zugänglich zu machen, auf meinem Webspace verfügbar machen. Gibt es ein Best Practice wie ich das Frontend von der Service API trenne?

 

[Umbel]

Dadurch das du deien API in einer eigenständigen Anwendung konsumierst ist es doch schon getrennt?!

 

[Rossie]

Ich muss ja, um die API anderen zugänglich zu machen, auf meinem Webspace verfügbar machen. Gibt es ein Best Practice wie ich das Frontend von der Service API trenne?

Da keine Angaben zur bevorzugten Sprache gemacht wurden, hier mal ein Beispiel aus der Java-Welt: https://dropwizard.github.io/dropwizard/manual/core.html

DropWizard ist ein gutes, recht einfaches Framework für REST-basierte Anwendungen. Damit hat man sehr schnell einen Dienst aufgesetzt und kann sich austoben. Für den Einstieg sehr zu empfehlen. Spring hat eine etwas höhere Lernkurve, wobei viele Dinge ganz ähnlich sind und man insofern viel Wissen mitnehmen kann.

 

[crvn075]

Du könntest natürlich auch Anhand es anfordenden Application-Type eine hübschere Form ausliefern. Aber das wiederspricht eigentlich der Idee eines Service.

Es widerspricht jedenfalls nicht der REST-Idee, welche Content-Negotiation als wesentliches Merkmal besitzt. Egal, ob dabei json, html oder pdf rauskommt. Diese Vorgehensweise scheitert aber meiner Ansicht nach an einem anderen Punkt: was bringt es, einzelne Ressourcen als HTML darzustellen? Mit einer Website hat das ja dann noch nicht viel zu tun. Siehe z.B. die Startseite von Computerbase, die sich aus News, Forenbeiträgen, Downloads usw. zusammensetzt; also nichts, was aus REST-Sicht eine einzelne Ressource wäre (oder eine Auflistung gleichartiger Ressourcen).

Von dem her ist die von dir vorgeschlagene Idee (Oberfläche konsumiert Service) wohl alternativlos.

Da keine Angaben zur bevorzugten Sprache gemacht wurden, hier mal ein Beispiel aus der Java-Welt: https://dropwizard.github.io/dropwizard/manual/core.html

Damit lassen sich ohne weiteres Zutun aber auch "nur" Ressourcen als HTML darstellen, oder? Denke der TS würde gerne eine richtige Website ausliefern.

 

[fhtagn]

[quote="Sam Bucca]Gibt es ein Best Practice wie ich das Frontend von der Service API trenne?[/quote]

Das kannst du so machen wie es am besten passt. Z.B. einen Webkontext für statische Inhalte (html, css, img, js usw.) und einen zweiten für die REST-API:

# Beispiel 1
/html             # statischer Inhalt
/api              # REST-Daten

# Beispiel 2
/                 # statischer Inhalt
/api              # REST-Daten

Das Frontend kannst du mittels Javascript direkt im Browser umsetzen.

Schematischer Ablauf:

• '/index.html' wird im Browser geöffnet
• '/js/meinRestScript.js' steht im HEAD und wird nachgeladen
• das Script registriert sich für ein Javascript-Ereignis, das informiert, wann die Seite fertig geladen wurde
• fragt dann die REST-Schnittstelle ab: GET /api/daten/5
• und passt das Seiten-DOM mit den geladenen Daten an

Das ist wohl die einfachste Variante. Die meisten Frameworks erzeugen dynamische Inhalte im Grunde nach diesem Schema.

 

[Sam Bucca]

# Beispiel 1
/html             # statischer Inhalt
/api              # REST-Daten

# Beispiel 2
/                 # statischer Inhalt
/api              # REST-Daten

In die Richtung ging meine Frage.

Gegeben sei folgendes Szenario (PHP):

Sei die Document Root des Webservers "/".
Frontend: "/html", "/html/index.php", "/html/css", "/html/js", etc
Service API: "/api"
URL: "http(s)://meine-seite.de/"

Wenn die URL auf "/html" zeigt, dann komm ich von außen nicht mehr an die Service API. Wenn die URL auf "/" zeigt, wie leite ich dann Browser Requests an "/html" weiter?

 

[Nase]

Mach eine Subdomain für die API.

 

[Sam Bucca]

Mach eine Subdomain für die API.

Hah, so einfach kann es manchmal sein

 

[Nase]

Du kannst natürlich auch dein url_rewriting so anpassen, dass Anfragen an meine-seite.de/api an den API-Ordner und Anfragen an meine-seite.de/ an den html-Ordner geleitet werden. Subdomain find ich aber schicker.

 

[Rossie]

Damit lassen sich ohne weiteres Zutun aber auch "nur" Ressourcen als HTML darstellen, oder? Denke der TS würde gerne eine richtige Website ausliefern.

Dropwizard ist modular aufgebaut. Es gibt fertige Module für statischen Content, Template-Engines (standardmäßig Freemarker oder Mustache), Datenbank-Anbindungen, Statistiken etc. Man kann damit ohne weiteres eine komplette Webseite erstellen. Ganz ähnlich wie mit z.B. Laravel.