So using Rails' REST resources routing, we end up with auto-generated routes that coordinate with Controller actions (I'll refrain from ranting about how I've replicated models twice, as well as relationships twice (as models and then as (often) nested resources; as well as actions twice (as I limit my resources with onlys/excepts where applicable and then code only those actions into the controller; so effectively my controller's public methods ARE my actions...anyway, I digress)
- GET /resources/new --> POST /resources --> REDIRECT GET /resources/:new_id
- GET /resources/:id/edit --> PUT /resources/:id --> REDIRECT GET /resources/:id/
The thing that's turned into a major head-scratcher for me is when a validation halts the save and backs out to render :new / render :edit But at that point, the client's URI is pointing not at .../new or .../:id/edit anymore. This seems to break the REST paradigm badly; because we haven't changed state yet we've transferred. Maybe that's why I've struggled so long to accept RESTful practices in a non AJAX or WebService scenario where calls can be made and processed without page change. In true REST resource representation, we shouldn't be pointing at a resources/:id/edit, but simply be inferring from a PUT verb.
In the old days of Rails we'd have the .../new form point back at new with a controller conditional like request.post? . If validations failed for whatever reason, it was okay to not redirect to a GET but the user was still at .../new, which made sense. They could press reload over and over and as long as our Controller checked the new action for a POST vs a GET, it would just continue to error, or reload the blank form. On success we'd move on with Get/Post/Get pattern.
SO, what's the general consensus (I know I could hack the POST/PUT data into the flash but I'd prefer something clean) on what to do about the resource location switch, and on fail, now displaying the 'new' form on what should be a 'show' or 'index', based on the URI (and incorporating Rails' .../new || .../edit paradigm) ?
(Secondary question : How should/could we handle getting information about a resource before a POST or PUT if practicing true REST, which touts itself as great because there is no broadcast contract of schema, as per say SOAP. In other words, to avoid 'hacks' such as .../edit and .../new (it's certainly looked at as bad form if, in REST approach, list other verbs in the URI .../show, .../delete, etc because the presence of a verb in the URI diminishes it's aspect as Resource and not a object.method pair )