In most examples I saw the incoming data (for example for creating new entity) data is POST'ed as form encoded. This is great for 'flat' objects, but I need to transfer more complex objects (2-3 levels of nesting). Is it acceptable to transfer them in the body of POST request as JSON-encoded string?
As long as you set the proper header to application/json and generally use the HTTP mechanisms of content negotiation: yes, this is acceptable.
json and form-data are media types. Pick what you want and be sure to set the content-type to the one you've chosen.
I believe JSON is commonly used to communicate arrays within the body of a document. I am using it here to transfer this array of mapped points and associated attributes http://ageara.com/test/map-service.php?action=listpoints ... albeit not with REST style ;-)
Related
I know that with openapi 3 I can use oneOf/anyOf but currently we can't upgrade to openapi 3. In one of definitions I need to use many response types which doesn't have common attributes (basically response is interface without any method/attribute and has multiple different implementations). Can I somehow define multiple response types with openapi 2? Is it possible to use for example headers/content-types/... to distinguish between this reponse types and have valid openapi2 definition?
thanks
Update:
Turns out there can be multiple responses as long as they have different HTTP status code as a "key". default keyword is just that, user of API is supposed to expect that if HTTP status is not on the list of responses default should be used. (e.g. if somebody uses switch to handle responses default maps to default case in switch).
As for single HTTP status code signaling multiple possible types of response, that's not supported explicitly. One ugly workaround would be to create type that contain all the fields, and it would be up to a client to discriminate based on which fields hold values.
I am developing a restful API. My create Reservation method requires parameters like data, location etc. It also requires a list of People. Those people have name, birthdate etc.
So to pass the people to the API I need to send a nested object to the API. This is something that I usually don't see out there in the API world.
So my question is: Are there any problems with this and should I somehow flatten the parameter object or is it no problem at all to accept a nested object as parameter?
There will be no problems with this but usually its not preferable because consumer of API need to understand the nested JSON and construct while calling. API having simple request JSON and syntax is always preferable.
This type of strategy is totally linked to modeling and coupling with the information-producing system.
In my opnion, if the resources can be structured sequentially as child resources, in this way the navigation and resuabilidad becomes more interesting. To minimize the number of calls a design pattern API Gateway with agragation is being pretty much in today by corporations.
Example:
POST http://api.teste.com/clients/ --> This is going to create a new client resource and returning the new client identification
POST http://api.teste.com/clients/1/addresses
I'm using restkit in my project and trying to post object to our rest api server with postObject request:
postObject:path:parameters:success:failure:
Restkit documentation says: parameters - the parameters to be reverse merged with the parameterization of the given object and set as the request body.
But what if I want my parameters to be like in getObject so "The parameters to be encoded and appended as the query string for the request URL."
What is the idea behind? Why Restkit developers made parameters to be merged with body? If I want them to be merged with body I would make those fields in my model class to be mapped in body.
Is there any way to make request with query parameters to be added to url and body?
Thanks in advance.
It's like an unwritten rule for working restful API's. Whenever you use GET you just reach to an endpoint with required query parameters. You are just giving the key parameters to reach (im)mutable data. For example;
.../accounts?name={name}
There is just no need to send a whole body for this when all backend needs is just an id to search.
There is nothing like you can't send body within GET or use POST with query parameters but these API's are tend to work like that.
Whenever you POST something to a restful API you are actually saying that I want to create something on your side with this given data. Representing objects are easier with a body if you are going to submit that value to the backend.
Also there is something called JSON-rpc. I might be wrong but it basically use POST for everything. You are even using for GET-like actions and sending body within. So you can even do GET actions with POST and bodies.
It's not a must but easier to work with this representation.
Is it possible to map the different objects to the same url and use different post params to differentiate between the return types?
My API isn't really rest. Everything flows through the same URL but has a parameter "Type" that differentiates the result that should be returned.
'Probably' - it would be nice it you added a few examples to the question (requests and associated responses).
Sending the requests is fine, though you will need to explicitly specify the path / route name to use.
For the response, you will most likely need to use an RKDynamicMapping which will inspect the incoming data and return the appropriate mapping to use.
If you can't tell the 'type' from the response data (instead, you can only tell because of the URL that was requested) then you may need to try mapping into all types and rejecting invalid content using KVC validation, or you might want to change your data model (not enough information in the question to determine which...).
I'm getting up to speed with the WCF Web API. I want to expose an endpoint that can accept notes, via the POST method. My issue is, I want to support multiple representations for notes. For example, I might want to accept a note using a custom XML serialization that we're using elsewhere, or as an atom:entry element. I already have formatters that can deserialize these into a Note class (our own custom class) or as a SyndicationItem.
The question comes though, how do I define the method? I've currently got this:
[WebInvoke(UriTemplate = GetNotesUriRoot,Method="POST")]
public HttpResponseMessage PostNote(ObjectContent item,HttpRequestMessage request)
Which fails when starting up:
The service operation 'PostNote' will never receive a value for the input parameter 'item' of type 'ObjectContent'. Ensure that a request HttpOperationHandler has an output parameter with a type assignable to 'ObjectContent'.
I initially tried having two separate methods (with appropriately typed parameters), but they can't share the same endpoint name. The current effort (using ObjectContent) was based on other posts I could find that suggested that it could be a parameter. There is no common base type or interface between Note and SyndicationItem
We're using v0.6.0 of the WCF Web API
You need to have a parameter / return type of type Note and your formatters will (de-)serialize it to / from the required representation.
[WebInvoke(UriTemplate = GetNotesUriRoot,Method="POST")]
public HttpResponseMessage PostNote(Note note)
then in your request the content-type header will determine how the object is deserialised. You don't need to worry about deciding how to deserialise, the decision is made for you, as long as the relevant formatter exists (I've not delved in to formatters yet as json/xml have been enough for me so far)