Rails core - Sep 2006 - Fwd: [WSG] REST HTTP error codes and responses for form/parameter validation

The current ActiveRecord::Errors#to_xml just spits out the  
full_messages. Though Rick has that working by pulling out bits of  
strings it doesn''t really help non-ActiveResource XML consumers, and  
hey, it''s XML, so why not put it in an attribute instead?

http://dev.rubyonrails.org/browser/trunk/activeresource/lib/ 
active_resource/validations.rb?rev=5068

Below is my post to a discussion on the web standards group list I  
started just the other day.

(Awesome work BTW Rick. ActiveResource is coming together quite nicely!)

-- tim

Begin forwarded message:
> From: Tim Lucas <tim@aviditybytes.com>
> Date: 8 September 2006 4:02:40 PM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] REST HTTP error codes and responses for form/ 
> parameter validation
> Reply-To: wsg@webstandardsgroup.org
>
> <snip />
>
> The current Rails approach for validation errors when trying to  
> create resources is to return "400 Bad Request" with the
following
> response:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <errors>
>   <error>Password confirmation can''t be blank</error>
>   <error>Password is too short (minimum is 4
characters)</error>
>   <error>Password can''t be blank</error>
>   <error>Login is too short (minimum is 3 characters)</error>
>   <error>Login can''t be blank</error>
>   <error>Email is too short (minimum is 3 characters)</error>
>   <error>Email can''t be blank</error>
> </errors>
>
> It could definitely be improved by at least including the resource  
> attribute the error relates to:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <errors type="ActiveRecord::Errors">
>   <error attribute="password_confirmation">Password
confirmation
> can''t be blank</error>
>   <error attribute="password">Password is too short
(minimum is 4
> characters)</error>
>   <error attribute="password">Password can''t be
blank</error>
>   <error attribute="login">Login is too short (minimum is 3
> characters)</error>
>   <error attribute="login">Login can''t be
blank</error>
>   <error attribute="email">Email is too short (minimum is 3
> characters)</error>
>   <error attribute="email">Email can''t be
blank</error>
> </errors>


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---

On 08/09/2006, at 4:38 PM, Tim Lucas wrote:
> (Awesome work BTW Rick. ActiveResource is coming together quite  
> nicely!)
Sorry, and of course DHH for laying the ground work :)

-- tim


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---

> > The current Rails approach for validation errors when trying to
> > create resources is to return "400 Bad Request" with the
following
> > response:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <errors>
> >   <error>Password confirmation can''t be
blank</error>
> >   <error>Password is too short (minimum is 4
characters)</error>
> >   <error>Password can''t be blank</error>
> >   <error>Login is too short (minimum is 3
characters)</error>
> >   <error>Login can''t be blank</error>
> >   <error>Email is too short (minimum is 3
characters)</error>
> >   <error>Email can''t be blank</error>
> > </errors>
> >
> > It could definitely be improved by at least including the resource
> > attribute the error relates to:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <errors type="ActiveRecord::Errors">
> >   <error attribute="password_confirmation">Password
confirmation
> > can''t be blank</error>
> >   <error attribute="password">Password is too short
(minimum is 4
> > characters)</error>
> >   <error attribute="password">Password can''t
be blank</error>
> >   <error attribute="login">Login is too short (minimum
is 3
> > characters)</error>
> >   <error attribute="login">Login can''t be
blank</error>
> >   <error attribute="email">Email is too short (minimum
is 3
> > characters)</error>
> >   <error attribute="email">Email can''t be
blank</error>
> > </errors>
Looks good to me, except for the type attribute of <errors>.

Any thoughts on using 400?  I know that''s kind of a generic status
code, but none of the others really fit.


-- 
Rick Olson
http://weblog.techno-weenie.net
http://mephistoblog.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---

Wouldn''t a ''409 Conflict'' make more sense for errors?

I realize how we serve out data via a REST API (i.e. XML data format,  
HTTP status codes, etc.) is pretty manual/flexible at this point and  
everyone is probably doing things a little bit differently (some  
people are using slightly different status codes, some people are  
formatting xml a little differently, etc.)

What sort of guidelines should we be looking to follow to help our  
APIs be "ActiveResource-compatible"? Is it too early for that right  
now? Do you think things will get to the point to where Rails will  
make it difficult NOT to conform to the ActiveResource conventions? I  
know that''s generally the idea with most best-practices for Rails,  
but I don''t see things quite being there yet in terms of generating a  
REST API.

On Sep 8, 2006, at 7:46 AM, Rick Olson wrote:

Looks good to me, except for the type attribute of <errors>.

Any thoughts on using 400?  I know that''s kind of a generic status
code, but none of the others really fit.



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---

On 9/8/06, Chris Abad <chris@integralimpressions.com>
wrote:
>
> Wouldn''t a ''409 Conflict'' make more sense for
errors?
>
I''m using 400 for validation errors and 409 for stale object errors
(optimistic lock failed).

jeremy


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---

On 09/09/2006, at 12:46 AM, Rick Olson wrote:
> Looks good to me, except for the type attribute of <errors>.
If 400''s are only ever going to represent validation errors then we  
don''t need the <error type="validation">.

I''ll put together a patch for the <error attribute="">.
Relying on
the full message isn''t going to sit well with the i18n folk.
> Any thoughts on using 400?  I know that''s kind of a generic status
> code, but none of the others really fit.
Yeah, nothing else really makes sense.

-- tim


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---

> If 400''s are only ever going to represent validation errors then
we
> don''t need the <error type="validation">.
>
> I''ll put together a patch for the <error
attribute="">. Relying on
> the full message isn''t going to sit well with the i18n folk.
Sending back english strings isn''t going to be too useful for
non-interactive users of an api,   perhaps we need to think about also
including some kind of ''error code''.  i.e.

<error attribute="first_name"
code="invalid.format">First name must be
letters</error>

Using those two values people can deduce what''s wrong without just
chucking a string up to a user.   This is pretty critical when your
web service call isn''t going to be handled by a user who can read the
strings and figure out what''s going on.

Anyone have any opinions on this?



-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---