Closed shadowhand closed 9 years ago
cc @bvisness
Technically, the Payload status types are not HTTP status types. They are domain-specific, not UI-specific, so the user interface is in charge of determining what to do with each payload based on its status. (The HTTP-type status and Payload status do map well to each other for a lot of cases, though.)
If you're talking about a GET-after-POST situation, e.g. to redirect to updated content after editing, I imagine all that's needed is a "success" or "updated" type of status. An Update-specific Responder would then specify a redirect to the URL for the ID of the edited content.
Does that help at all?
Also, if you need it, it's perfectly reasonable to create your own Payload statuses specific to your domain. I'd expect different domains to have different statuses specific to them; the ones with the Payload package are generic.
Ah ha, rubber duck moment. The use case had to do with checking if a user is logged in, which is a NOT_AUTHENTICATED
status. We just need a custom responder to does a redirect instead of a 401 status.
Thanks!
Quack quack. :-)
How do we create a payload that redirects to another location? I don't see anything in the current statuses that would be semantically correct.