Validations and nested resources

[Mark Burns]

Hi

I've been wondering about how you would handle the concept of a nested resource within Collection+JSON.

It might be nice if the structure of Collections/Items could have a tree like structure.

E.g. for creation of a blog post for at the same time as signup for a user, it might be nice to have something like

{ "collection" :
  {
    "version" : "1.0",
    "href" : "http://example.org/friends/",
    
 ...
    
    "template" : {
      "data" : [
        {"name" : "full-name", "value" : "", "prompt" : "Full Name"},
     ...
        {"name" : "password",  "value" : "", "prompt" : "Password"},

        {"nested_resource": "blog_post":,
         "data": 
          [{"name" : "title", "value" : "", "prompt" : "Title"},
           {"name" : "body",  "value" : "", "prompt" : "Body"}
          ]
        }
      ]
    }
  } 
}

Also I feel that having a clearer means of expressing validation issues on a per-field basis would be useful.

At the moment the spec only has a single object for expressing error information:

// sample error object
{
  "error" :
  {
    "title" : STRING,
    "code" : STRING,
    "message" : STRING  
  }
}

So I think it may be useful to be either a little more flexible and allow an array of Objects for conveying detailed error messages, or

perhaps add an optional attribute like error message to the template

 "data" :
    [
      {"prompt" : STRING, "name" : STRING, "value" : VALUE, "error" : {"message" : String, "code": STRING} },
      {"prompt" : STRING, "name" : STRING, "value" : VALUE, "error" : {"message" : String, "code": STRING} }
    ...
    ]
}

What do you think?

Cheers,

Mark

[mca]

Mark:

good to see you continue to work w/ CJ. and good POVs in this post, too.

1) i strongly advise against a nesting model for CJ. it turns out to
be pretty a "big step" ahead in writing a state-machine client that
handles nesting and i am not convinced the payback is worth it. in
the case you present (login + blog post) i'd using a single template
with data elements names in helpful ways (i.e. "login-username",
"blogpost-title:", etc.). FWIW, login data should be done out of band
(i.e. via HTTP.WWW-Authenticate & HTTP.Authorization headers), but i
know folks like to present UIs, too.

Another alternative would be to use a "templates: []" array that hold
multiple named templates (possibly w/ diff href properties as targets
for the "send"). I know of at least one other case where the
templates: [] array is used.

2) the error:{} object is designed to provide message-level feedback
(not field-level). I can see that you might want to provide some
field-level information for data elements and i think that's a good
extension. i'd consider (off the top of my head) something like this:

data : [
{name : "email-address", value : "", prompt : "Your Email:",
validate: {regexp: "...", message : "Invalid or missing email",
required: true, type: "string"}}
]

there might be other/better ways to do this; love to hear feedback.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

[Mark Burns]

Hi Mike

I'll have another think about what you've said wrt nesting and authentication before

making any comments.

I think the validation stuff could get complex and could be a little more than just regex based.

Also I'd guess it's better to handle that stuff in the application.

However, it did get me thinking about the idea of code-on-demand.

It seems like it would be nice to provide javascript validation functions in responses, although

I'm not clear on the security implications of that. Presumably a client wouldn't want to be

using untrusted code, and you'd only want to do it over a secure connection.

[mca]

yeah, in the design, i specifically left out inline code. it's really
tempting w/ JSON to just slip code right in, but i don't think it's a
good idea. adding a link to javascript files might be OK. in that
case, i'd adopt a rel value of "script" to make sure clients can
ignore the script or sandbox it, etc. as needed.

you can get quite a bit of field-level validation using regexp! you
can also skip the regexp an use named types (ala HTML5 w/ email, url,
etc.).

what you cannot do easily w/ regexp is group-level or dependency
validation (i.e. if you select "other-service" checkbox, then
"service-name" is required., etc.) i don't attempt that in markup
media types right now. instead, i do that either in the client code or
the server code.

i left the validation markup out as it's an "addition" and folks have
their own ways of doing things. for now, feel free to work up an
extension that makes sense for you and post it here. we all might
learn some cool stuff!

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me