Strategy for RESTful Placement of Multiple Objects

Question

I still feel comfortable doing REST things.

In my situation, the client software will interact with the RESTful service. Rarely will a client load its entire entity database (each object is serialized into approximately 5kb xml fragment).

Maybe I'm wrong, but the correct RESTful strategy seems to be to loop through each entity and individually POST each. However, there may be tens of thousands of these entities, and anyway, so many fast-fire POST messages do not seem kosher.

In this situation, it seems that packing all entities into one large xml view will violate the RESTful way of doing things, but it will also eliminate the need for thousands of POST.

Is there a standard practice for this? Thanks in advance!

Answer 1

There are at least two problems here that prevent you from being RESTful.

• Each resource must be identified using a URI. An action on a resource means that you must call the URI with an HTTP call. Therefore, you cannot invoke multiple actions on multiple resources with just one HTTP call.

• Resources are identified by nouns and represent entities. This means that to insert Employee and Car you need to call two different resources for each of the corresponding objects.

Thus, in summation, you cannot use a purely RESTful approach here. However, REST is intended to be an aid in the form of conventions, not limitation. The best solution here is to create a custom action that does what you need.

Alternatively, you can create a common wrapper object with INSERT, UPDATE, and other actions that take in disparate data blocks as XML. However, this undermines your other endpoints because it is now possible to insert a Car record through a common shell and through a URI /Car/ .

Unaware of your actual requirements, I would advise you not to disclose this function with REST. Behind the scenes, you can still invoke your INSERT action methods in different controllers, as soon as you break the incoming collection if there are disparate objects.

Answer 2

I do not understand why the "package of objects" cannot be considered a resource. Transactional records can of course view a database transaction as a resource. I admit that I am not reading the Fielding dissertation, but I do not see how transferring multiple resources into one view will invalidate REST.

Database operations do something like this. They will wrap smaller resources inside the transaction resource. It’s true that they usually do this so that you can post these smaller resources, which can still be large, separately. But since the transaction itself is considered a resource, I don’t think that coming up with a view for it that you could place as a single POST request will make this project less RESTful.

It was also used in a different direction. When the client receives the search results from the server, the server can wrap them inside the results resource so that the client can simply get this one resource instead of several separate ones.

So, I would say that wrapping these small 5kb resources inside a larger collection resource can be considered RESTful and probably this is the way you should go.

Answer 3

As long as the large shell has a valid type of media file, it is perfectly treated as a separate resource. Finding out what this media type will be is a tricky part.

Answer 4

Nothing prevents you from creating additional resources when adding, as well as publishing a resource, which is an X list for a resource that contains an X list using POST.

Then you send back 201, created with a URIS list of all created resources. Again, all this is perfectly acceptable.

What you are losing is visibility for PUT intermediaries that prevent them from caching or changing a specific resource in a particular URI. Although a smart broker will process 201 for caching purposes.

And if you have no obstacles, each created resource has its own post-creation URI (after POST) and includes PUT / DELETE in these resources. Or a combination.