2017-04-10 3 views
1

Referenzierung diese API Tutorial/Erklärung: https://thinkster.io/tutorials/design-a-robust-json-api/getting-and-setting-user-dataWarum verwenden Sie DELETE/POST anstelle von PUT, um einen Benutzer "nicht zu bedienen"?

Das Tutorial erklärt, dass zu 'einem Benutzer folgen', verwenden Sie:

POST /api/profiles/:username/follow.

Um 'einen Benutzer unfollow', verwenden Sie:

DELETE /api/profiles/:username/follow. Das Benutzerprofil besitzt zunächst das Feld "following": false.

Ich verstehe nicht, warum das Feld "following" erstellt/gelöscht (POST/DELETE) anstatt von true zu aktualisiert wird. Ich habe das Gefühl, dass ich nicht begreife, was tatsächlich vor sich geht - schalten wir nicht einfach den Wert von "Following" zwischen true und false um?

Danke!

Antwort

0

Ich denke, dass die Datenbankschicht in einer etwas komplexeren Art und Weise als nur mit einer booleschen Spalte für "Following" implementiert werden muss.

Wenn Sie drei Benutzer haben, was würde es bedeuten, dass einer der Benutzer "following": true hat? Folgt dieser Benutzer etwas? Das allein kann nicht bedeuten, dass der Benutzer allen anderen Benutzern folgt, nicht wahr?

Die Datenbankschicht besteht wahrscheinlich aus (mindestens) zwei verschiedenen Konzepten: Benutzer und Folgen; Benutzer enthalten Informationen über den Benutzer, und folgende geben an, welche Benutzer einander folgen.

sagen, dass wir zwei Benutzer haben:

[ 
    {"username": "jake"}, 
    {"username": "jane"} 
] 

Und wir wollen sagen, dass Jane Jake folgt, aber nicht umgekehrt.

Dann brauchen wir etwas, das dieses Konzept darstellt. Nennen wir, dass ein folgendes:

{"follower": "jane", "followee": "jake"} 

Wenn die API Gespräche über das Erstellen oder Löschen von folgenden, ist dies wahrscheinlich ist, was sie sich vorstellen, erzeugt zu werden. Aus diesem Grund verwenden sie POST/DELETE statt nur PUT. Sie modifizieren das Benutzerobjekt nicht, sie erzeugen andere Objekte, die folgendes darstellen.

Der Grund haben sie einen "following": true/false Teil Antwort in ihrer JSON-API ist, weil, wenn Sie Informationen zu einem bestimmten Benutzer fragen, als einer der anderen Benutzer, Sie, wenn Sie wissen mögen, wie ein Benutzer, dass bestimmten Benutzer folgt .

das obige Beispiel so, da, wenn jane für Informationen über jake fragen würde, bei GET /api/profiles/jake, würde sie so etwas wie diese erhalten:

{ 
    "profile": { 
    "username": "jake", 
    "bio": "...", 
    "image": "...", 
    "following": true 
    } 
} 

Wenn jedoch jake für die Profilinformationen fragen würde über jane, würde er stattdessen diese Antwort erhalten:

{ 
    "profile": { 
    "username": "jane", 
    "bio": "...", 
    "image": "...", 
    "following": false 
    } 
} 

Also, die Informationen, die sie auflisten, wie die API-Antwort ist nicht das, was tatsächlich in der Datenbank zu diesem bestimmten Benutzer gespeichert wird, ist es auch contai ns einige Informationen, die basierend darauf berechnet werden, wer die Frage gestellt hat.

+1

Die Datenbankschicht sollte für die Designüberlegungen der API nicht relevant sein. Die Semantik von POST/DELETE vs. PUT ist nur für die API-Ebene relevant. –

+0

stimme ich zu. Ich habe das nur als Beispiel benutzt und vielleicht war es ein ungeschickter. Ein "following" ist in diesem Fall ein separates Konzept von einem "user profile", und das ist natürlich das, was uns das verlinkte Beispiel ebenfalls sagt. Die Frage fragt, ob wir nicht nur einen booleschen Wert umschalten. Das gab mir die Idee zu versuchen, einen Grund zu erklären, warum sie sprechen, dass Folgen erstellt/gelöscht werden, und nicht nur, warum die Profilantwort vor und nach einer Folgeanfrage anders aussehen würde. – Frost

0

Die Verwendung eines microPUT wäre sicherlich eine sinnvolle Alternative. Ich glaube nicht, dass irgendjemand Ihnen sagen kann, warum ein zufälliges API-Tutorial bestimmte Designentscheidungen getroffen hat. Es könnte sein, dass sie nur ein künstliches Beispiel für die Verwendung von POST/DELETE benötigten.

Wenn der Autor diese Frage nicht sieht, erwarte ich, dass sie nicht zu beantworten ist. Es ist denkbar, dass sie Metainformationen speichern möchten, wie z. B. den Zeitstempel der Statusänderung, die jedoch von POST/DELETE vs. PUT nicht beeinflusst werden.

Verwandte Themen