When I implement a method annotated with #JsonApiSave in my katharsis repository I get a fully populated resource as a parameter, even though the PATCH request is only sending a single attribute. Is there a way I can find out which attributes have been updated?
Related
We are implementing CRUD interface to manage entities with SOAP messages. What are good practices to allow partial updating of the entity? Meaning the client could update just some attributes of the entity, without having to post the whole entity? Is there more general approach to this than distinct methods for each attribute update?
HTTP Patch can be used for partial updates, only sending the fields of the object you want to change. There's an interesting discussion about partial updates here.
I'd say it would be more important to make sure the partial update is idempotent, i.e. the same update fields in the request result in the same end state of the resource. So if you have internal logic that determines the state of a resource attribute based on the value of another resource attribute that is being updated that might be something to look into. e.g. if the resource as a whole has rules for when parts of it are updated but other parts are not specified (default values for some attributes?), that may cause different outcomes based on the current state of the resource.
If the resource as a whole is just a collection of unrelated attributes then partial updates make sense but if there are dependencies among some attributes and some get updated while others don't, then the end state of the resource has to be idempotent. e.g. does it make sense to update an address but not update the phone number? What happens to the phone number if it's a landline and the address gets updated? Is it set to null? and vice versa. So when doing partial updates it might be worth 'partitioning' the allowed partials based on the domain being updated.
I have a RESTful API method that creates/updates an entity (e.g POST /classes or PUT /classes/:id) with a few parameters. One of the parameters (e.g. teacher) is an ID of some other entity of a different kind.
My question is what is a correct response code for this method when the entity indicated by the parameter doesn't exist (or the user has no access to this entity).
My choice is (for both POST and PUT methods):
404 if the entity from parameter doesn't exist,
403 if we have no access to the entity from the parameter (but the information about existence of this entity is not a secret),
404 if we have no access to the entity from the parameter (in case the information about this entity should remain a secret).
I feel that this is very descriptive and clear (along with some error message). However, I'd like to consider potential alternatives or have a confirmation that my approach is not a bad design.
The 404 (Not Found) status code indicates that the origin server did
not find a current representation for the target
resource or is not willing to disclose that one exists.
-- RFC 7231
Emphasis mine. 404 is a non-sensical error in the use case you describe, because of course there is no current representation of the target resource - you're trying to create it. 400 would be a better status code, along with a response object explaining that the referenced object doesn't exist.
In fact, your case is not specified in RFC. Every status should refer to the entity (resource) requested by the URL. If non-existing resource is a parameter, then it is not a "target entity". The most adequate status is 400.
I am implementing a REST api for setting and retrieving a resource.
I have been asked to implement a strange PUT, whereby a JSON object is stored, while another JSON object is returned.
PUT /object/{id} - stores the object with a specified identifier, and returns properties about that object in a different object
The upstream team is requesting this purely for convenience - one action (the storage of the object) is always followed by a request of derived information (based on the contents of the object).
In my mind, in a RESTful api, these would be two calls: one to store the object, then another to retrieve some data about that object id.
PUT /object/{id} - stores the object with a specified identifier
GET /object/{id} - retrieves the object with a specified identifier
GET /object/{id}/properties - retrieves properties about the object
One thought I had was to expand the object itself to include space for the "derived properties", so that the PUT sends in an object that is essentially incomplete, and then the returned object is returned with the completed properties data. I have seen many apis branded as RESTful that return a copy of the actual object stored, so this is the basis for this approach, but I have not seen an api that appended additional data.
What is the RESTful approach to obtain this derived data?
Based on the recommendation by APIGEE in their RESTful API Design blog post I wish to implement the fields query-string parameter to allow mobile application clients to restrict the content returned from a single RESTful API call. For example:
domain.site.com/rest/accounts/{id}?fields=name,id,age
If the fields parameter is omitted then a complete account resource will be returned. My question is how would I implement this on the server using Jersey (for example). Since Jersey makes it easy to return an Account POJO but I am unsure how to restrict the fields of the resulting JSON object based on the 'fields' query-string parameter.
There's not an automatic way to do it. Your service should load the entire object and then null out the fields you dont' want. Make sure the beans are annotated to ignore null fields in the json serialization and then return the object after you've modified it to remove the fields you dont' want.
I have a Product object with a property that is a collection of type Workflows. In my "GetProducts" method on the domaincontext object I have set a breakpoint at the return statement to see if the workflows collection is filled.
It is.
On the client side I check Context.Products[0].Workflows in another breakpoint and I see 0 results. Is there a way to persist this nested data for consumption on the client side or is RIA Services inhibited from doing this?
If you have or can download the RiaServicesOverviewPreview.pdf document section 4.8 details how to do this. The basic summary it.
Make sure your L2S query specifies the .LoadWith<>() parameter. Lazy loading doesn't work with RIA services so you have to use implicit loading.
You need to apply the "IncludeAttribute" to the associated member. For example add the [Include] attribute on your Workflows field in the Product metadata class.
Ensure that your Workflow (child) type is exposed as a client type so it gets genned to the client side.
You can get the document here: http://www.microsoft.com/downloads/details.aspx?FamilyID=76bb3a07-3846-4564-b0c3-27972bcaabce&displaylang=en
I should kick myself. I realized that I needed to add "[Include]" to the property in Product within the DataService.metadata.cs file and now it gets sent to the client.