In spring data rest if we POST to a collection resource, it would create that object. But why does it updates it(replaces completely) if the POST request json payload contains an object which is already present in db.?
Shouldn't it throw conflict exception or something similar? After all spring data rest says that POST to a collection resource would create a new object.
Spring says ,
Request that the resource at the URI do something with the provided entity. Often POST is used to create a new entity, but it can also be used to update an entity.
https://spring.io/understanding/REST#post
So you will need to make the #id in the request null (or remove it from the req) if you want to save it as a new record.
Related
So I am using postman to retrieve all the activities information under one automation. But I have trouble retrieving the activity types.
The response I got was:
<soap:Body><RetrieveResponseMsg xmlns="http://exacttarget.com/wsdl/partnerAPI"><OverallStatus>Error: The Request Property(s) AutomationTask do not match with the fields of Activity retrieve</OverallStatus><RequestID>----</RequestID></RetrieveResponseMsg></soap:Body>
Hence, I am curious if there is a list of request properties that I can use (like a documentation for the activity object type properties) in the soap api call.
I have tried https://developer.salesforce.com/docs/marketing/marketing-cloud/guide/automationactivity.html but not much luck, some of the fields are unable to retrieve.
According to the RFC Put is used to update an existing resource.
But, the Stripe API uses Post to update objects. Why is this?
For example, in the Stripe Node Library
update: stripeMethod({
method: 'POST',
path: '{id}',
}),
the update method calls POST
I understand that there is no Patch method since the entire resource must be sent on every call, by why is the Put HTTP Verb not used in that case?
(Unlike this example from an SO question about the Facebook API, the resource is identifiable by a single ID that is passed in the URL) eg the URL is simply /v1/customers/:id
Interesting question! From your link:
The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already
existing resource, the enclosed entity SHOULD be considered as a
modified version of the one residing on the origin server. [emphasis mine]
This means you must PUT the entire resource (changes and and non-changes alike). Very few APIs are designed that way.
From the spec for POST:
The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line. POST is designed
to allow a uniform method to cover the following functions:
Annotation of existing resources;
Many/most APIs have adopted POST as the way to update objects.
Some additional thoughts here: https://stackoverflow.com/a/25909372/379538
I'm currently building a Web API in net-core that has the following requirements:
All web transactions must have a unique Guid identifier for each endpoint
If an endpoint is hit with a previously used Guid, then the response that was given for this Guid is returned again
I was attempting to implement this by JsonSerializing the IActionResult inside the WebApi controller, but I ran into an issue where I can't deserialize all IActionResult responses since some don't have a constructor.
For example:
JsonSerializationException: Unable to find a constructor to use for type Microsoft.AspNetCore.Mvc.CreatedResult. A class should either have a default constructor, one constructor with arguments or a constructor marked with the JsonConstructor attribute.
Does anybody know if it's possible to work around this?
Personally, I'd use the response caching middleware. You can make it vary on your GUID, so as long as that is included in the request, it will only render the action if the GUID is different.
Short of that, if you want to handle this manually, cache the JSON you're intending to return, not the full response object. Then, you do not need to re-query the database, etc., and you simply return the response, which is not all that much overhead.
In my app, I have this scenario where I need to post an object to remoter server and get an object key back and then store the object locally. I have Core data and Restkit implemented in my app.
The object value are collected from user input. I couldn't figure out a great way to prepare the object before posting it to remote server. This object is an entity of type NSManagedObject, and I don't want to store it before I get the object id from server.
I came across this which suggested to use a transient object to handle this situation. But as discussed in that thread, this causes issue with code maintenance.
Is there a better way to handle this scenario? Thanks.
Make your core data model class adhere to the RKRequestSerializable protocol.
Then when the user input is validated, create an entity as normal and set it as the params value to the RKRequest, this will send your object as the HTTP body. Look inside RKParams.m for an example.
Also set the newly created entity as the targetObject for the RKObjectLoader. That way, when your web service returns the information (like the new unique ID), it will target the new object and save the new unique ID to this object without creating a duplicate.
Clear as mud?
PS: Oh and be careful mixing autogenerated core data classes with custom code! I recommend mogen to help you not lose code each time you make a change.
What is the proper way to version media types in openrasta? Up to this point on one of our rest api's we specified custom media types with the version number in them:
application/vnd.company.Entity-v1+xml
Currently all of these media types are just being passed to a custom codec that we defined to remove some of the default tags and ns tags that XmlSerializer puts in on serialization. At the top of that codec we have:
[MediaType("application/vnd.company.Entity-v1+xml")]
Now we're to the point where we have clients that want custom attributes and elements in the xml and have thus created a new entity that handles those attributes and elements that derive from Entity. We now have the task of moving specific clients up to the new entity (EntityV2), however I'm not sure how to handle this in the context of OpenRasta when it comes to getting this new entity type into the handlers. Here's what we've thought about thus far:
Add another POST method to our handler to handle the derived type
Create a completely new url to handle the new entity
Create a new media type and then route the requests somehow to a new handler. This would be the most effort as we are trying to reuse the same handler with a small amount of decision logic to determine what needs to be done with the new elements/attributes.
Any advice would be greatly appreciated!
I'm an OpenRasta noob, but I think the best approach might be to use the same handler for both versions of the requests, and just introduce a new codec for the new versions of the entity.
I believe if you create a new codec and decorate it with [MediaType("application/vnd.company.Entity-v2+xml")] it should use that codec to deserialize the request instead of the v1 codec. The OR content negotiation should take care of using the proper codec, so your handler wouldn't change.
This depends on whether your clients can be expected to use the "Accept" HTTP header to indicate which version of the entity they are using. If that's not the case, you can still create a new URL and just configure it with your existing handler and the new codec.
Make sense?