Jsonapi-resources: clarify batch creation of nested objects

[Fivell]

Hello, what is the way of batch creating of nested objects, like accept_nested_attributes does in rails.

Fo instance how can be implemented batch POST of order with order_items or something similar

[lgebhardt]

We don't currently have support for batch operations. We're waiting for the extensions to gel in the JSON API spec before adding support.

[Fivell]

@lgebhardt, any workaround ? How would you suggest to build API method to create resource if it is not valid without it's nested objects (order has_many order_items, company has_one address, etc)

[lgebhardt]

Well the basic architecture was designed with the idea that we'd be supporting batch operations. The Request object parses the request data and turns it into different Operations, when then get run through the OperationsProcessor. I would start by modifying the Request object to accept your complete set of data and turn it into multiple Operations. I suspect the rest of the code should handle the set of Operations correctly. The one issue you may run into is if you choose to use server generated ids. There is currently no logic in JR to supply one operation with the results from other operations. So getting access to the address when you go to create the company may prove problematic. If possible I would use client generated ids.

[Fivell]

not long time note about complex objects was merged to json-api. http://jsonapi.org/format/#document-resource-object-attributes

It is still not very clear about creating resource, but nested objects might be presented as array inside complex attribute.

So it might looks likes

POST /orders HTTP/1.1
Content-Type: application/vnd.api+json
Accept: application/vnd.api+json

{
  "data": {
    "type": "orders",
    "attributes": {
      "discount_code": "4168647591205773",
      "order_items": [
            {
              "item_name": "socks"
               "qty": 5
            },
           {
              "item_name": "t-shirts"
               qty: "1"
           }
        ]
    }
  }
}

[lgebhardt]

That could work for create in simple cases, but given the spec specifically excludes the links and relationships it would be of limited use for more complex nested objects. The best approach would be to push for the spec to include support for this so we can implement it in a standard way. However I'm sure a few minor modifications could get this working.

[selaromi]

Hello @lgebhardt ! Could you please clarify what changes have to be made to accept nested resources creation? Is there a way to make it work with server generated ids?

Thanks!

[lgebhardt]

@selaromi First, anything you do won't be JSON API compliant at this point. But to hack this into JR you would need to modify the Request class to accept the new format and create the operations and the CreateResourceOperation class contain the new request data and insert it into the models.

I'm sure it could be made to work with server side ids. The tricky part is that the operations in JR stand alone at this point. So in the above example you couldn't just create three CreateResourceOperations because the order_items wouldn't know the order id until the order is saved into the database. So you would need a way of tracking the id. Probably the simplest approach would be to allow an operation to have a parent operation where the new id could be looked up from. So create one CreateResourceOperation and two CreateDependentResourceOperations (this is a new operation class that does not currently exist). The CreateDependentResourceOperation class would have a link to the CreateResourceOperation and could use that to look up the id from that operation.

That's just one way it could be approached. Once the JSON API spec spells out the format for nest resources I hope to get this feature into JR.

[arcreative]

@Fivell I know it's not optimal, but when I need this sort of functionality, I start by creating the parent record with some sort of draft state, then assign things to it and save them as the user creates them. In the case of an address (belongs to), I would create that first since it doesn't have any dependencies, then create an order that depends on it. The downside here is that you have draft models that might need cleanup and multiple requests would need to be made, but other than that it works pretty much the same way. It actually provides autosave-like functionality for your client experience as well. I've come to embrace it, it doesn't seem to be that bad for lack of true batch support.

[Subtletree]

Did anyone build this in their app? If so I'd be grateful if you posted the relevant code, cheers!