Dies ist eine Art Follow-up-Frage zu dieses eine .
Sie haben also eine eindeutige Antwort auf einen bestimmten URI als Hauptmieter einer RESTful-Architektur? Eine Menge Diskussion hier tendiert in diese Richtung, aber ich habe es nirgends als eine "harte und schnelle" Regel gesehen.
Ich verstehe den Wert davon (für Caching, Crawlen, Passing Links, etc.), aber ich sehe auch Dinge wie die Twitter-API es verletzen (Eine Anfrage an http://api.twitter.com/1/statuses/friends_timeline.xml wird basierend auf dem angegebenen Benutzernamen variieren), und ich zu verstehen, dass es Zeiten gibt, in denen es notwendig sein kann - nicht zu erwähnen, dass sich eine chronologisch ausgelagerte Ressource auch ändert, wenn neue Elemente hinzugefügt werden.
Sollte ich versuchen, verschiedene Antworten aus demselben URI zu eliminieren, oder akzeptiere ich einfach, dass es manchmal nicht praktikabel ist, und solange ich sein Auftreten minimiere, werde ich in einer anständigen Form sein.
Nicht die selbe Antwort, sondern eine Repräsentation (die von den Headers von conneg und bedingten Anforderungen abhängt) der gleichen Ressource . In einer Restarchitektur identifiziert ein URI eine und nur eine Ressource (aber eine Ressource kann mehrere URIs haben). Das Präsentieren unterschiedlicher Ressourcen in Abhängigkeit von dem autorisierten Benutzer (HTTP-Auth, Cookies, ...) ist eine schlechte Übung, da derselbe URI für jeden Benutzer eine andere Ressource darstellt, wie im Twitter-Beispiel. Ich kann Ihnen nicht erlauben, meine Zeitleiste anzuzeigen und Ihnen die URI zu geben, da dies die gleiche URI für Ihre Zeitleiste ist. Der Benutzer muss in der URI codiert sein und der Zugriff muss durch den Autorisierungsmechanismus begrenzt sein. Um einen einzelnen Zugriffspunkt zu verwenden, der abhängig vom authentifizierten Benutzer eine andere Ressource darstellt, verwenden Sie eine Umleitung (z. B. 303 Siehe Sonstige, 302 Gefunden, ...)
Nichts in REST sagt die gleiche Antwort - aber Sie sollten darauf vorbereitet sein, Dinge wie die "If Modified Since" -Anfrage-Header zu behandeln, WENN SIE SENSE MACHEN;)
Die Tritter-API hat natürlich noch andere Probleme - wie in: Dies ist eine Designentscheidung. Wenn Sie zum Beispiel zulassen, dass Freund-Zeitlinien isoliert werden, würde es Sinn machen, die Zeitleiste unter ein Element für einen Freundennamen zu setzen - sie haben sich offensichtlich dagegen entschieden;)
Es kommt darauf an, Entscheidungen zu treffen. Betrachten Sie OData (wie Ссылка ) - hier macht es Sinn, die gleichen Daten für jede URL für eine bestimmte Zeit zurückzugeben (Caching) , weil es ein völlig öffentlicher Katalog ist. Für andere Szenarien kann es keinen Sinn ergeben.
Einige Anforderungsheader ändern, was zurückgegeben wird (während sie noch RESTful ist):
Accept kann verwendet werden, um das Format der Antwort (HTML vs XML vs JSON) Authorized kann zumindest bestimmen, ob eine 401, 403 oder 200 zurückgegeben wird. Die eigentliche Frage ist, ob der Header Authorized (der den Benutzer bestimmt) verwendet werden kann, um den Inhalt der Antwort zu ändern. Ich habe keine offizielle Aussage darüber gesehen, aber ich vermute, dass eine Anzahl von Leuten lieber den Benutzer in der URL und dem Authorized Header haben würde, um den Zugang zu validieren. Ich vermute, dass jeder Weg noch RESTful ist.