On Mon, Sep 16, 2013 at 11:27 AM, Michael Jett <[email protected]> wrote:
> On Sun, Sep 15, 2013 at 6:30 PM, Chris Geer <[email protected]> wrote: > > > Since we've been having a lot of discussions on data structures lately I > > wanted to write down what my suggestions were. These aren't 100% complete > > examples but show the relationships > > > > CRUD Interfaces > > > > Page (/pages/<page-id>) > > { > > id: <id>, > > owner: <owner>, > > regionIds: [ > > <id>, <id>, <id> (region order is based on order in list, not field > > on region object) > > ] > > } > > > > Region (/pages/<page-id>/regions/<region-id> > > { > > id: <id>, > > regionWidgetIds: [ > > <id>, <id>, <id> (widget order is based on order in list, not field > > on region widget object) > > ] > > } > > > > Region Widget > > (/pages/<page-id>/regions/<region-id>/regionwidgets/<region-widget-id> > > { > > id: <id>, > > widgetId: <widgetId>, > > collapsed: <collapsed>, > > ... > > } > > > > Region Widget > > Properties > > > (/pages/<page-id>/regions/<region-id>/regionwidgets/<region-widget-id/properties/<propertyId>) > > { > > .... > > } > > > > Widget (/widgets/<widget-id> > > { > > id: <id> > > title: <title> > > } > > > > > > Render Interface (custom mime-type) (Read Only) > > > > Why would we define a custom mime-type other than JSON? > Let Chris tell me if I am wrong, but I assume this is so you can have the read-only endpoint with the same URL structure of '/pages/<page-id>' but have one be read only and have one be the regular rest endpoint which can take post and put. > > > > > > /pages/<page-id> > > { > > id: <id>, > > regions: [ > > { > > id: <id>, > > regionWidgets: [ > > { > > id: <id>, > > widgetId: <widgetId>, > > title: <title>, > > properties: [ > > { > > key: <key>, > > value: <value> > > } > > ] > > } > > ] > > } > > ] > > } > > > > You should also be able to render sub elements below a page so for > example, > > > > /pages/<page-id>/regions/<region-id> with the custom mime-type would > render > > a single region. > > > > > This makes sense. It's possible to map this to an angular $resource. > I understand you can map this to an angular resource, but this means when calling save you either have to remove the read-only properties before saving, or save them with them there to the correct update endpoint just ignoring them on the server. If you are going to leave the read-only properties attached when saving, I don't see what we get from the read-only endpoint instead of just adding a few immutable fields to the REST model. > > > > > > Obviously there is still room for uncertainty in some places. For > example, > > what happens if your have a region with three region widgets then you > save > > the region but only include two ids in the list? > > > > > > Personally, I think that > > should delete the missing regionWidget because that list denotes > ordering. > > The reason I don't like an "order" attribute on the sub objects is that > > what if you save two sub objects with the same order (which would happen > if > > you ever wanted to swap two objects in order because you have to update > > them then save each one so they would have the same order at least > > momentarily on the server)? > > > > Anyway, my 2-cents. > > > > Chris > > > Dan
