2.1.Ressourcen

2.1.)Ressourcen

Ressource	Methode	Semantik	content-type(req)	content-type(res)
/artist	GET	Gibt alle vorhandenen Künstler zurück.	text/plain	application/json
	POST	Erstellt einen neuen Künstler.	application/json	application/json
/artist/{:id}	PUT	Überarbeitet den Künstler mit der gewählten ID.	application/json	application/json
	GET	Gibt den Künstler mit der gewählten ID zurück.	text/plain	application/json
	DELETE	Löscht den Künstler mit der gewählten ID.	text/plain	text/plain
/genres	GET	Gibt alle vorhandenen Genres zurück.	text/plain	application/json
	POST	Erstellt ein neues Genre.	application/json	application/json
/genres/{:id}	PUT	Überarbeitet das Genre mit der gewählten ID.	application/json	application/json
	GET	Gibt das Genre mit der gewählten ID zurück.	text/plain	application/json
	DELETE	Löscht das Genre mit der gewählten ID.	text/plain	text/plain
/songs	GET	Gibt alle vorhandenen Songs zurück.	text/plain	application/json
	POST	Erstellt einen neuen Song.	application/json	application/json
/songs/{:id}	PUT	Überarbeitet den Song mit der gewählten ID.	application/json	application/json
	GET	Gibt den Song mit der gewählten ID zurück.	text/plain	application/json
	DELETE	Löscht den Song mit der gewählten ID.	text/plain	text/plain
/songs/?name=name	GET	Gibt Songs mit bestimmten Titel zurück.	application/json	application/json
/songs/?artist=artist	GET	Gibt Songs von bestimmten Artists zurück.	application/json	application/json
/songs/?genre=genre	GET	Gibt Songs von bestimmten Genre zurück.	application/json	application/json
/users	GET	Gibt alle vorhandenen Benutzer zurück.	text/plain	application/json
	POST	Erstellt einen neuen Benutzer.	application/json	application/json
/users/{:id}	PUT	Überarbeitet den Benutzer mit der gewählten ID.	application/json	application/json
	GET	Gibt den Benutzer mit der gewählten ID zurück.	text/plain	application/json
	DELETE	Löscht den Benutzer mit der gewählten ID.	text/plain	text/plain
/queue	GET	Gibt die komplette Warteschlange in sortierter Reihenfolge zurück.	text/plain	application/json
	POST	Hängt einen neuen Song an das Ende der Warteschlange.	application/json	application/json
	DELETE	Löscht das erste Lied der Warteschlange.	text/plain	text/plain
/queue/{:id}	PUT	Überarbeitet die Warteschlange an der Position ID.	application/json	application/json
	GET	Gibt den Song an der Position ID in der Warteschlange zurück.	text/plain	application/json
	DELETE	Löscht Lied aus der Position ID aus der Warteschlange.	text/plain	text/plain
/queue/allowedGenres	PUT	Fügt ein Genre zu den erlaubten Genres dazu.	application/json	application/json
/queue/allowedGenres	GET	Gibt alle erlaubten Genres zurück.	text/plain	application/json
/queue/allowedGenres/:{id}	DELETE	Löscht erlaubtes Genre mit ID.	text/plain	application/json
/users/:{id}/class	GET	Liste aller Nutzerklassen	text/plain	application/json
/users/:{id}/class/:{id}	DELETE	Löscht Nutzerklasse	text/plain	text/plain
/users/:{id}/class	POST	Erstellt neue Nutzerklasse	application/json	application/json
	PUT	Ändert Nutzerklasse	application/json	application/json
/	POST	Erstellt einen Eintrag zu den erlaubten Genres.	application/json	application/json

###Definition der Ressourcen:

Zunächst haben wir uns die logischen Ressourcen überlegt, welche notwendig sind um alle Funktionen zu erfüllen:

• songs - Musikstücke mit ID, Titel, Artist-ID & Genre-ID
• genres - Musikgenres mit ID & Name
• queue - Playlist als Liste mit Songs als Eintrag

Die Ergänzung von weiteren sinnvollen Ressourcen, kam während der Überlegungen von ganz alleine:

• artists - Künstler mit Namen, ID & IDs der gespielten Genres
• users - Benutzer mit ID, Name & Benutzergruppe
• allowedGenres - Subressource von Queue: Genres, welche gespielt werden dürfen

Bei der Ressource "artists" & "genres" haben wir etwas länger überlegt, ob es sinnvoll ist, hierfür eine eigene Ressource anzulegen. Ausschlaggebend für eine Implementierung waren schließlich die Gründe, dass der Code auf diese Weise übersichtlicher bleibt und wir auch in Zukunft mehr Möglichkeiten haben.

Zu Beginn gab es auf alle Ressourcen den DELETE- Befehl, dies erschien uns aber als schlechte Entscheidung, da es so leicht zu einem versehentlichen Entfernen der Einträge in der Datenbank führen kann. Nun gibt es bei allen Ressourcen, außer bei "queue", nur das Löschen einzelner Inhalte über die ID. Bei der Queue wird bei einem DELETE- Befehl auf die Ressource das erste Element der Liste entfernt, da so das "Hören eines Songs" besser simuliert werden kann.

Das Nutzersystem wird in der 1. Entwicklungsphase gar nicht entwickelt, in der 2. Phase ist eine Implementierung durchaus denkbar.

Kursiv sind die noch zu implementierenden Ressourcen für die 2. Phase gekennzeichnet, welche aufgrund von Zeitmangel leider noch nicht umgesetzt werden konnten.

Bei den gestrichenen Ressourcen handelt es sich im ersten Fall um die Gruppierung der Benutzer, wie "User" oder "Admin, wo wir uns erstmal offen halten wollen, ob diese über eine extra Ressource definiert wird. Momentan ist für uns aber eine Definition über ein Attribut der Ressource "users" sinnvoller.

Im zweiten Fall handelt es sich lediglich um die erlaubten Genres, welche vom Nutzer festgelegt werden müssen. Da der POST- Befehl auf das Wurzelverzeichnis aber unüblich ist, haben wir das ganze dann doch als Subressource über queue/allowedGenres eingebunden.

Da wir ein Routingsystem für bessere Übersichtlichkeit verwenden, sind alle Ressourcen über `localhost:3000/api/ erreichbar. Das ermöglicht zudem noch eine bessere Trennung zum Dienstnutzer.