In his Addressing fragments in REST Simon St. Laurent says …
REST offers a great way to build simple applications that Create, Read, Update, and Delete resources. But what if you want to get at part of a resource?
and
The problem is that developers can’t address the resource on which they want to work with sufficient granularity given their current set of tools and agreements.
Right. The answer that works best is, well, make the fragments addressable! PATCH is nice, but comes at a cost, cost for clients understand how to describe the patch, cost for the server to decode the patch format. Just like the case of batch, I would keep the bar higher for using PATCH. Time and again, I was reminded that granular resource modeling is not always possible, and time and again, I would repeat that, granular resource model is the first step that MUST be considered before uttering PATCH or BATCH.
{ 2 comments… read them below or add one }
In my experience, this discussion of ‘addresssable fragments’ comes up when folks are not clear on the true meaning of ‘resource.’ I think of a resource as an abstraction of some data on the server. As long as you only think of a resource as a ‘full document’ or some other type thing, fragments will be an issue.
But if you do as you suggest (make the target addressable), then we need to deal with fragments. Of course the server has some work to do sorting out what is addressed and how to keep the data in sync, but that’s where this *should* happen – not on the client.
>> As long as you only think of a resource as a ‘full document’ or some other type thing, fragments will be an issue.
Well said.
>> Of course the server has some work to do sorting out what is addressed and how to keep the data in sync, but that’s where this *should* happen – not on the client.
Well said, again :)