RESTful Rails Put/Post fail problem

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; 开发者_JAVA百科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 )

If you really want to URL to stay the same, you can always implement client-side validation and disable the 'Create' or 'Update' button; this means you can skip the if-else loop and just throw an error if the save still fails.

If you look at the default Rails XML routes, it often does not even have a new and edit method, but just returns XML with the generated errors. This is actually the same for the HTML, except that Rails handles it gracefully and allows a user to retry immediately.

Of course, if you really want to get rid of the /new and /edit 'hacks' (as you call them), you can include a 'new' form on the index view and include the ability to edit a resource on the show view of that same resource.

Another improvement would be to return a 422 (:unprocessable_entity) instead of a 200 on the else in the create and update method; this if often implemented for the XML output, but mostly not done for the HTML output. Then you would at least indicate to the client the input it gave wasn't valid.