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.
Related
I am new to nestJs, Before I would learn nestJs, I have learnt fastify. In fastify, If I want to filter the response data I would define JSON Schema. it will filter out my server response data. But in nestJs I don't know how to do that. Even If I have define the JSON schema. Then the filtered data only shown in swagger. and it doesn't work to filter data unlike fastify. It will be cause for more security issue.
For Ex: There is an API,Which is used to create user, When that API is called, an user will be created. And the server will send the user data to that API response. In my case the server will send all data about created user including password. If I want to remove the password from response. I need to manualy frame the object. But in fastify, which is automaticaly handles the response depends on JSON schema. here my question is, this is possible in nest js
Friend, If you please let me know.
Sounds like you're looking for Serializtion of the response. You'd create a response model of your API, similar to a schema but class based with the appropraite class-transformer decorators, and return an instance of that class from your API, letting the ClassSerializerInterceptor handle serializing the response for you
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
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...).
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 ;-)
I'm using Openrasta for my RESTful webservice and I've a small doubt with regards to the method parameters and URI
For example: I've following Setup for user entity.
Configuration:
ResourceSpace.Has.ResourcesOfType<User>()
.AtUri("/user")
.And.AtUri("/user/{userId}")
.HandledBy<UserHandler>()
.AsJsonDataContract()
.And.AsXmlDataContract();
Handler method for PUT:
public OperationResult Put(long userId, User user){}
URI for the same will be http://localhost/User/1
Request body will contain a JSON as below:
{
"userId":1,
"userName":"FirstName"
}
Here, my question is: Defining the PUT method with two parameters is correct or not? If it is right way to do that, then userId parameter in the PUT method will contain same value as User entity property UserId.
And, in the PUT method I need to verify whether these two values are same or not and if they are not same I return BadRequest stating that URI doesn't match with the entity provided in request. Why should we do this explicitly why not it can be handled while processing the request and have PUT method take only User entity as parameter? Am I missing anything drastically or is my understanding about this design completely wrong? Any thoughts or opinions please?
There's a few reasons for it.
First, it's a technical limitation of how URI parameters are processed and matched to inputs one variable at a time. The same gets applied to key/values codecs, so that ought to let you have one User object. but when you use a json codec, we get back a full object, so that would end up overriding User alltogether.
The second one is that I never tried to fix that problem, mostly because combining uri parameters and response bodies leads to a whole bunch of hidden security issues you probably want to stay well clear of.
Last and not least, from a modeling perspective a ReST API ought to use URIs as identifiers and links instead of foreign keys, so if you already have your identifier (the URI), there's little reason why that should be modeled in your entity body.