I created a method in order to upload an image to my server by using web api. However I need to send additional parameters while sending multipart form data. What I want to do is to create a methods which gets required parameters and uploads to desired place by looking that parameters. The method is as like as below
public void AddPhotoItemData( int UserID, int QuestID, int QuestTemplateItemID, double Latitude, double Longitude)
What I COULD NOT do is to trig this method while sending multipart form data and these parameters at the same time. Is there anyway to upload a file with a method that has parameters?
Regards,
KEMAL
The method in your question uses an RPC style signature which runs against the grain of the uniform interfaces that an HTTP based API provides. Look at this good blog post to see what are the "philosophical" differences between RPC and HTTP based APIs.
The Web API facilitates creating HTTP based APIs. This implies you'll be sending "representations" to specific URIs using the standard GET/POST/DELETE & other HTTP methods. That's why multiple "parameters" in a "call" aren't really supported without wrapper of some sort.
Related
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.
I am writing some webservices using spring. I wanna know what's the argument to the service methods: domain objects or request parameters? for example a "User" object or a bunch of strings containing name, e-mail, etc.
Depending on your configuration (and the method signature) you will receive unmarshalled objects (Jaxb for instance), the MessageContext and so on.
Take a look in the documentation, you'll find some examples and everything you need to know about the service methods and parameters.
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)
I have been trying to find some step by step guidance on how to take a user's inputs (e.g.) name address, etc) via the view, to write that to xml, and then to submit that set of data to a third party interface (e.g UK Companies house xml gateway)
I have some aspects in hand (i.e. GET side of view to collect the data), but can't seem to get my head around using the controller and POST to submit the actual thing!
If anyone can steer me to a "For dumboids" tutorial, I'd highly appreciate it
Thanks
Paul
Side stepping the issue of whether you should be posting from your controller, you can use code like the following to post xml to a url. In the example below "xml" is your xml string and "url" is the url you want to post to. (Note: WebClient is built-into the .NET framework)
// create a client object
using(System.Net.WebClient client = new System.Net.WebClient()) {
// performs an HTTP POST
client.UploadString(url, xml);
}
I would question whether the controller should be posting directly to the XML gateway - this sounds like the job of a domain/business object sitting behind the controller, ideally referenced by an interface.
This was you can test your controller without requiring it to hit the XML gateway, and simulate the success/failure conditions.
If you can get the data already, I'd consider:
IGatewayPoster poster = ...
poster.Submit(dataSentFromView);
In the GatewayPoster class do the actual work of communicating with the XML gateway.