Nesting: object/array as property value or action field?

[theefer]

From the spec and the examples (in this repo and of sample APIs), I wasn't able to confirm whether Siren supports arrays or objects as values for properties or fields.

For example, for the properties, is the following valid Siren?

{
   "properties": {
      "name": "Tom",
      "permissions": ["admin", "god"], 
      "address": {
         "street": "21 Sample St",
         "city": "Orlando"
      }
   }
}

And in terms of fields, is it possible to describe an action that would require the client to send one of the following strings of JSON:

{
   "name": "Tom",
   "permissions": ["admin", "god"], 
   "address": {
      "street": "21 Sample St",
      "city": "Orlando"
   }
}

or

[1,2,3]

[apsoto]

I'm not aware of SIren restricting the value of a property. I have had
cases where I use an array.

On Sat, Feb 7, 2015 at 12:18 PM, Sébastien Cevey [email protected]
wrote:

From the spec and the examples (in this repo and of sample APIs), I wasn't
able to confirm whether Siren supports arrays or objects as values for
properties or fields.

For example, for the properties, is the following valid Siren?

{
"properties": {
"name": "Tom",
"permissions": ["admin", "god"],
"address": {
"street": "21 Sample St",
"city": "Orlando"
}
}
}

And in terms of fields, is it possible to describe an action that would
require the client to send one of the following strings of JSON:

{
"name": "Tom",
"permissions": ["admin", "god"],
"address": {
"street": "21 Sample St",
"city": "Orlando"
}
}

or

[1,2,3]

—
Reply to this email directly or view it on GitHub
#43.

[ericelliott]

For example, for the properties, is the following valid Siren?

I hope so, or I'm going to have to change a whole lot of code. ;)

[theefer]

Cool, thanks for the feedback on properties. Maybe this could be made clearer in the spec?

How about values in the fields definitions of actions?

[GrahamFirst]

@kevinswiber What's your take on this?

[kevinswiber]

Yes, the properties attribute is just a valid JSON object.

I'm not entirely sure what you mean by the second question. Action fields map to HTML5 input types, though support for radio and checkbox are not well-defined at this time.

There's also no clear and easy way to include support for JSON along with a JSON schema. I've hammered this in before using a single text field, but it's not ideal.

There are more issues with actions, but before I keep guessing, maybe you can clarify a little. :)

[theefer]

@kevinswiber What I meant was how do you describe an action in your API that requests sending fields that are themselves objects, e.g.

{
   "name": "Tom",
   "permissions": ["admin", "god"], 
   "address": {
      "street": "21 Sample St",
      "city": "Orlando"
   }
}

name can be type: "text", but what about permissions or address?

Full disclaimer: I work on the argo media-type, which we have been using in multiple projects for a couple of years. It is fairly similar to Siren in many ways. One thing argo is currently missing and I'm looking into adding is the support for "actions". I wanted to review how Siren does it to see if the same semantics could be adopted, but I'm worried the use of HTML5 input types makes it hard to specify richer structures.

[kevinswiber]

@theefer

Ah, I see. Your permissions field can be a checkbox type, but again, that hasn't been very well-defined at this point. I do it one way. Someone else will do it another way. It's a hole that needs to be patched in the spec.

The address object is a little more complicated. I often flatten the structure. So I'd have an address.street field of type text and an address.city field of type text. Some folks just set action.type to application/json and add an additional property pointing to a JSON Schema file, though this isn't called out as a supported option in the spec.

[theefer]

Thanks for the clarification.

JSON Schema is something I'm considering as it seems more generic and expressive, though I know it's sometimes reproached for being too complex and, well, expressive.