Handling Collections of Resources

[smizell]

In my original pull request, I included a rule for appending _urls to a property to define a list of URLs. However, after some thinking, I'd like to start more discussion around. I think we should step back and discuss what this is actually doing and think through if this solves that job.

I originally wanting a way to embed a list of URLs as a type of collection resource. But I ended up including multiple of these _urls properties, which moved it from a collection resource to a collection of collections. It makes it confusing.

Also, as mentioned by @fosrias, you need to resolve the URLs to do anything with them.

The question is is then, how do we encourage good design of collection resources?

[smizell]

Now my personal thought: I don't think _urls solves the issue of good collection design, and I therefore propose we remove it from the spec.

I would then think through how can we encourage a collection design that captures what Ion's collection and Collection+JSON capture. I'm not sure this should go in the main design pattern doc, but maybe for something external.

[fosrias]

Well, people often don't do collections in json correctly => {[...]}. I actually read an article why doing this is actually a security risk, but for the life of me I can't remember why. They are easy in JSON IMO if you just do an object with list member in it. It won't be like CJ, where you can put collections of anything in the same bucket, but who ever really does that anyhow?

[smizell]

Yes, JSON makes this easy. The simple pattern would be to use an items property that is an array of objects. This would be in addition to any domain-specific properties and links. This is of course all domain specific, so people can do whatever they want.

The next pattern would be to use next_url, prev_url, first_url, last_url, and maybe up_url to help with pagination and navigation. But this is more of a "pagination" pattern than a "collection" pattern as shown above.

My point would be that:

1. I don't think any of this fits into the main spec of RESTful JSON
2. I think we can think of additional patterns to extend upon the RESTful JSON pattern

I think you could get really close to the CJ feature set minus the template area.

[fosrias]

I don't think we ever need to address this. I think RESTful JSON gives a pattern that can be used just fine for collections of resources when they are resolved as that collection as long as you don't do {[]}. IMO should just close this issue.

[smizell]

I may tackle this pattern somewhere else :)