What are the advantages of using a JSON string in the POST body as opposed to using key/value pairs in the POST body? It seems like there are a lot of API's out there that do it.
Example of what I mean: user={"username":"bob", "age":1} vs username=bob&age=1 in the POST form data.
When you use a JSON string, you just have to encode/decode your object and are ready to go. This especially useful when using multiple platforms.
Also, when you want to add new values/fields to your request, you just add it to the JSON object, instead of having to add extra validations in multiple files, possibly breaking code already works.
Another thing I can think of is that when using JSON you can code one single component with the only purpose of send/receive data, where you declare the function that will receive the decoded JSON and do whatever it wants with it. That way, you don't repeat code and let every function/class/file/whatever do the specific functionality it's meant to.
Related
I am currently working on a REST API for a project. In the process I should search for events. I would like to make an endpoint for searching events in a period. That is, specify two parameters with from - to.
For the search you normally take a GET operation. My question is now it makes sense to specify two parameters in the path or should I rather fall back to a POST operation for something like that.
Example for the path /Events{From}{To}
Is this even feasible with multiple parameters?
If you are not making a change on the resource, you should use GET operation.
More detailed explanation:
If you were writing a plain old RPC API call, they could technically interchangeable as long as the processing server side were no different between both calls. However, in order for the call to be RESTful, calling the endpoint via the GET method should have a distinct functionality (which is to get resource(s)) from the POST method (which is to create new resources).
GET request with multiple parameters: /events?param1=value1¶m2=value2
GET request with an array as parameter: /events?param=value1,value2,value3
I am designing my first REST API.
Suppose I have a (SOAP) web service that takes MyData1 and returns MyData2.
It is a pure function with no side effects, for example:
MyData2 myData2 = transform(MyData myData);
transform() does not change the state of the server. My question is, what REST call do I use? MyData can be large, so I will need to put it in the body of the request, so POST seems required. However, POST seems to be used only to change the server state and not return anything, which transform() is not doing. So POST might not be correct? Is there a specific REST technique to use for pure functions that take and return something, or should I just use POST, unload the response body, and not worry about it?
I think POST is the way to go here, because of the sheer fact that you need to pass data in the body. The GET method is used when you need to retrieve information (in the form of an entity), identified by the Request-URI. In short, that means that when processing a GET request, a server is only required to examine the Request-URI and Host header field, and nothing else.
See the pertinent section of the HTTP specification for details.
It is okay to use POST
POST serves many useful purposes in HTTP, including the general purpose of “this action isn’t worth standardizing.”
It's not a great answer, but it's the right answer. The real issue here is that HTTP, which is a protocol for the transfer of documents over a network, isn't a great fit for document transformation.
If you imagine this idea on the web, how would it work? well, you'd click of a bunch of links to get to some web form, and that web form would allow you to specify the source data (including perhaps attaching a file), and then submitting the form would send everything to the server, and you'd get the transformed representation back as the response.
But - because of the payload, you would end up using POST, which means that general purpose components wouldn't have the data available to tell them that the request was safe.
You could look into the WebDav specifications to see if SEARCH or REPORT is a satisfactory fit -- every time I've looked into them for myself I've decided against using them (no, I don't want an HTTP file server).
I want to update ONE SINGLE attribute on the Core Data Object and send the change to the server using RestKit.
I see that ResKit is always sending Object with ALL attributes and not only with the changed ones. That makes my app slow(er).
I also see that update response from server should return whole object back to the RestKit which is again slower that it could be (All I need is success/failure response)
Is there elegant solution for this? (I am pretty new to the RestKit)
You can create a request descriptor on-the-fly which includes only the attributes you want to send, you would either simply need to use a mapping operation yourself or be sure to only run one such operation at a time and call removeRequestDescriptor: on the object manager (this could be tricky for you to manage). The alternate is to put the data to upload into a dictionary and upload that, but that isn't ideal.
For the response, the mapping says what to map but it doesn't all have to be there, RestKit will take whatever it can and map that.
Synchronizing data once user gets online involves both Insert and Update (Upsert) and I'm sending both kinds of records in a single request (array) and then server iterates through records to determine insert or update.
My question is whether to use POST or PUT?
Also how a response from the server (JSON) should like in it's body? the data sent is an array, for example
{
"ids" : "15,16,17",
"success" : true
}
Edit:
And what should be the response code, it has both create and update operations:
200 OK
201 Created
REST is not CRUD. Mapping HTTP methods to CRUD operations is a convention introduced by some frameworks, but it has nothing to do with REST. Read this answer for some clarification on that.
A PUT is a complete replacement that ignores the current state of the resource. Think of the mv command in a shell. If there's nothing on the destination, it creates it. If there's something, it replaces completely, ignoring whatever is in there. That's how a PUT should work. Ideally, your application should have an uniform implementation of PUT that works in the exact same way with any URI that supports the method..
A POST submits the payload to be processed by the target resource under predefined rules. This means you can use POST for any operation that isn't already standardized by the HTTP protocol.
In your case, it's clearly not a complete replacement, so it's not a case for PUT. Use POST.
I'm new to Pentaho and using the Rest Client. I can get the Rest client to work by using generate rows for the url. But then I need to pass part of the result of the json to be part of the url for the next request. I'm not sure how to do this. Any suggestions.
Remember that PDI works with streams, you, for each REST request you made, you will have one row as result. You will have as many rows as many requests you do.
I'm not sure if you can deserialize the JSON object directly from the PDI interface, but in the worst scenario, you can use the "User Defined Java Class" to use some external library (like Gson) and deserialize the object.
Then, you can create another variable in the UDJC step and concatenate the attributes you need on the URL string that comes from the last step.
In the other hand you can use "Modified Javascript" to deserialize it and return the attributes you need to then concatenate it with the URL. To use it, just declare varibles inside the code, and then use "Get variables" button to retrieve the available fields to send to the next step.
There are many ways to do it, I suggest you to use the Modified Javascript because it's easier to handle.
You CAN parse the Json response, just use Json Input a a nex step, and then use XPath to parse the field you want: $.result.the.thing.u.want.