Ich entwerfe ein ruhiges API und versuche es zum ersten Mal richtig zu machen.
Ich habe einige verschachtelte Ressourcen definiert (Kommentare in einem Blogpost), und diese Auswahl spiegelt die Tatsache wider, dass Kommentare innerhalb des Blogpostdokuments in mongo verschachtelt sind.
Ich bin nicht daran interessiert, einzelne Kommentare außerhalb des Kontexts zuzustellen, daher habe ich die Implementierung von GETs für die verschachtelten Ressourcen verschoben. Es ist jedoch sinnvoll, POSTing für die Kommentarsammlung und PUTTING für einen Kommentar uri zu implementieren.
Spezifische Fragen:
1) Ist es sinnvoll, auf einen POST mit einem 201 und einem Location-Header zu antworten, der auf die übergeordnete Ressource gesetzt ist? Wenn nicht, wie kommuniziere ich den übergeordneten Standort, um Navigationsoptionen auf dem Client zu informieren?
2) Eine ähnliche Frage für PUT: Wie kann ich dem Client am besten mitteilen, dass er nach der übergeordneten Ressource suchen soll, um das Update zu finden? (vorzugsweise ohne dass der Kunde Annahmen über mein Uri-Schema machen muss). Ist der Location header auf einer 200 sinnvoll?
Obwohl ich es selbst nie gemacht habe, habe ich von Leuten gehört, die den Content-Location-Header für diesen Zweck verwenden. Content-Location wird verwendet, um den Speicherort der Ressource zu identifizieren, die von der zurückgegebenen Entität dargestellt wird.
Im Fall von PUT und POST möchten Sie möglicherweise nicht den gesamten Blogpost zurückgeben. Daher bin ich mir nicht sicher, wie gültig es ist, einen Content-Location-Header zurückzugeben, auch wenn Sie keine Repräsentation zurückgeben die Antwort.
Nachdem ich das gesagt habe, kann ich mir keine negativen Auswirkungen vorstellen, also hier ist was ich vorschlage:
%Vor%Tags und Links rest http-headers