Each request should get the same "logical" response. There is nothing wrong with the content varying with each request. A resource that represents "The last 10 items processed" will always contain just that, even if the response is different at the html level. This is why cache-invalidation is important.
A resource can also be composed of parts of other resources. For instance, you can have an order resource which is composed of item resources that each have their own url.
I think the rails flash is usually used to send a user a message which will only be seen once on the very next request. Think of the message as a resource that isn't important enough to get it's own url, and every resource as a composite of the actual item they are looking for and an optional "message" resource. The message resource isn't important enough to store into permanent storage. It could be stored into the db backend and then loaded up on the next request, and then deleted once the user has seen it. In practice that's not practical so it's kept in memory.
Consider: user submits form that loads slowly, application sets flash and slowly begins sending response. User gets bored and visits yoursite.com. Flash message appears on yoursite.com and does not appear on the page that is loaded after the form is submitted. Oops.
Flash message appears on yoursite.com and does not appear on the page that is loaded after the form is submitted. Oops.
Doesn't really seem like an oops to me.
State breaks the internet.
You submitted a form. That presumably changed the state of the resources at that url too.
The page should set the flash state when the state transition is done, not when it starts. It shouldn't matter if the user sees the message on the page after the form or from a different page altogether. What if every page had a history of all of the flash messages ever produced? You wouldn't call that "state" any more or less than the state of the objects you were trying to change in the form itself.
I think the part of this you actually don't like is that the following GET implicitly deletes the state (which is why we can optimize and store it in session rather than the db). But when the state is "messages unseen by the user" then it seems reasonable to me.
I think we can agree that any state where it matters what page they view the message on is probably not a good candidate for flash. I'm not even a rails programmer but I think there are better examples for the state-is-bad idea.
A resource can also be composed of parts of other resources. For instance, you can have an order resource which is composed of item resources that each have their own url.
I think the rails flash is usually used to send a user a message which will only be seen once on the very next request. Think of the message as a resource that isn't important enough to get it's own url, and every resource as a composite of the actual item they are looking for and an optional "message" resource. The message resource isn't important enough to store into permanent storage. It could be stored into the db backend and then loaded up on the next request, and then deleted once the user has seen it. In practice that's not practical so it's kept in memory.
I don't think it breaks the internet at all.