Spring RESTful best-practice - Beispiel/tutorial benötigt
KURZE GESCHICHTE:
Ich bin auf der Suche nach tutorial oder ein github-Projekt hat ein Beispiel für RESTful service design "best practices".
LANGE GESCHICHTE:
Ich werde durch die "offiziellen" Spring tutorial für die Gestaltung und Implementierung von web-services:
http://spring.io/guides/tutorials/rest
Es ist ein Beispiel für ein kleines Projekt. Sie sind mit "hexagonal architecture" und eine Reihe von "event" - Klassen für dieses Projekt. Durch Sie gehen, ich kann nicht helfen, aber beachten Sie, dass es scheint, viel zu over-engineered, für ein Beispiel-Projekt. Es gibt über 50 Klassen, nicht mitgerechnet die tests. Ist das wirklich der "best practice" - Beispiel für so ein service? Wenn nicht, gibt es andere Beispiele, die besser sind?
- Fragen Sie nicht, uns zu finden-tutorials für Sie. Verwenden Sie google, yahoo oder bing zu tun.
- Ich habe eine umfangreiche Suche. Das problem ist, herauszufinden, welche das sind gute Beispiele, und welche nicht. Wenn das offizielle tutorial scheint fraglich für mich, ich habe zu Fragen, ob ich bin einfach nur verrückt hier, oder nicht. Sanity-check.
- Ich denke, dass das Lernprogramm, auf das Sie verlinkt haben, geht einfach ins detail über das, was ein REST ist. In jedem Fall ist diese Art (wenn auch nicht ganz) off-topic.
- nützlich: github.com/gothinkster/spring-boot-realworld-example-app
Du musst angemeldet sein, um einen Kommentar abzugeben.
Kann ich nicht zeigen Sie Sie auf ein tutorial, aber kann erwähnen einige der Dinge, basierend auf der Erfahrung mit dem schreiben von RESTful-services mit Spring MVC.
split der Controller von der business-Logik. Bedenken zu haben, in der die Controller: die meisten von allen Fehlerbehandlung, auch potenziell Genehmigung. Die Controller-Methoden ist zwar Recht Dünn, anfangs, und nur der Versand zu entsprechenden business-logic-Methoden. Das ist nicht eine schlechte Sache, sobald Sie Ihr Controller wird wachsen mit Fragen der Verbindung von clients.
sprechen der Fehlerbehandlung, es ist ziemlich schwer zu bekommen es rechts in einen RESTful-Dienst. Sie müssen auf jeden Fall eine Möglichkeit haben, gut informiert die Kunden der Fehler, über strukturierte Daten. Das sollte einen Teil deiner Antworten, vermute ich. Sie müssen entscheiden, welche Fehler Sie zurück zu senden Informationen über, welche Sie schweigen darüber und melden Sie sich einfach, etc.
wahrscheinlich haben Sie einige der Daten-Objekte für die Anfragen, die Sie bekommen, und die Antworten, die Sie senden. Verpacken Sie in einem separaten Glas. Hinzufügen dieser jar-Schnittstellen implementiert, die von Ihrem Controller. Fügen Sie auch einen einfachen zweiten Implementierung dieser Schnittstellen macht, dass Anrufe auf Ihren service. Hier gehen Sie, Sie haben einen client-lib. Verteilen Sie es, machen Sie Ihre Java Kunden glücklich.
Obwohl jetzt haben Sie eine schöne Java-client-lib, vergessen Sie nicht, auch testen Sie Ihr service mit curl, und dokumentieren, wie Sie zu verwenden es auf diese Weise, mit einfachen telefonieren. Machen Sie Ihre nicht-Java-Nutzer können sich freuen.
Gibt es alle Arten von Bibliotheken für "unit" testen von Controllern, von Spott bis mehr oder weniger von der Interna von einem web-server. Diese sind sehr nützlich, aber nicht beschränken Sie sich auf Sie. Ein qa-env, wo Sie voll entfalten Ihren Dienst, und haben eine qa-app, die sendet echte vollwertige Anfragen an die Instanz des service auf der qa-env, und analysiert Ihre Reaktionen.
Versuchen, die Dinge einfach halten und konsistent über die verschiedenen Anrufe. Zum Beispiel mit jeder Reaktion enthalten kann, die die gleichen "Fehler" Teil, das die gleichen Felder mit Informationen in einem strukturierten Programm verwendbaren form über das, was schief gelaufen ist.
REST ist eine schöne Abstraktion, sondern hat seine Einschränkung: in der Praxis /löschen.json?id=3 kann sehr unterschiedliche Auswirkungen auf die verschiedenen Dienste. Erwarten Sie nicht, Ihre Kunden in der Lage sein, zu erraten, was "hinzufügen" und "löschen" bedeutet in Ihrem Fall, wie Sie wahrscheinlich erraten, anders aus, was Sie erwartet. Stattdessen bieten Sie in Ihrer Dokumentation einige Informationen darüber, was Ihren Dienst tun werden unter die Haube. Wir sind noch nicht in einem Stadium, wo wir sind in der Lage, Komponenten, die die Kommunikation über das wissen von nur einer sehr dünnen Oberfläche, bleiben agnostic Ihrer Interna, leider.