Given both:
NSData *jpegData;
NSString *xmlPost:
How do I construct an ASIFormDataRequest to post both the image/jpeg data and the applicaton/xml data as a multipart/mixed POST request?
I'm afraid that I'm not actually answering about your question.
Two facts.
The ASIFormDataRequest class is not designed to support 'multipart/mixed'. (at least, currently)
XML is just a plain string which can be sent via multipart/form-data too.
If your situation is forcing you have to use multipart/mixed, just ignore me. (for instance, your client don't want to modifying server program which support only multipart/mixed.)
If not, please think again once. Do you really need the multipart/mixed itself? No choice? Never 'multipart/form-data'? As I know, most server part programmers like 'multipart/form-data' more than other rarely used format because it supported by most server frameworks. So it makes their life a lot easier :)
If you really want another 'regularity' or 'efficiency' or some other specials instead of simplicity, you should consider other than HTTP. The only benefits of HTTP is stability and compatibility. (from it's well-defined specification and long history) This is most important benefits, but may not suitable for you.
I didn't try 'multipart/mixed'. Maybe it's possible someone has a simple way to do this.
But basically this is a kind of hacking job. (enabling feature which absent on original design) This should be painful. It'll be easier making your own class from the HTTP specification.
I strongly recommend you to use multipart/form-data instead of. Which is supported on the class by design. You can assume an XML source just like a plain string. Which can be sent via plain POST field value.
Related
I need to define an end-point for an action the back-end is supposed to take: format the device.
The end-point I have come up with is:
POST /device/{deviceId}/format
without any body.
This, doesn't look RESTful though. Or is it?
Is there any alternative for this ? How can I make it RESTful?
REST doesn't care what spelling you use for your URI.
https://www.merriam-webster.com/dictionary/stop
https://www.merriam-webster.com/dictionary/go
https://www.merriam-webster.com/dictionary/procrastinate
All of these identifiers work fine. The machines don't care, because they aren't trying to extract semantic information from the identifier. General-purpose clients consider the URI to be opaque (aside from certain purely mechanical concerns permitted by RFC 3986).
This, doesn't look RESTful though. Or is it?
It can be fine, there might be better choices. Caching is a very important idea in REST, and if you expect that a successful POST request will change one of the representations that the client may have cached, then you will want to think about how to communicate to the client that some cache entries need to be invalidated.
Another way of expressing the same idea; you might imagine that our API is a collection of objects. What you are trying do here is send a format message to the device. A simple spelling of this might look like
Resource(/device/{deviceId}).FORMAT()
But our problem is that FORMAT isn't part of the uniform interface currently defined by HTTP; and trying to come up with semantics for FORMAT that are consistent across all resources isn't worth the bother.
What's are alternative? It's okay to use POST.
POST serves many useful purposes in HTTP, including the general purpose of “this action isn’t worth standardizing.”
Resource(/device/{deviceId}).POST()
and that works fine. Of course, sometimes we have more than one action that isn't worth standardizing. How do we discriminate between them?
Resource(/device/{deviceId}).POST(format)
The general purpose components route the request to your post handler, then your bespoke code interrogates the request and forward it to the module in your code that specializes in handling formatting requests.
I have a url to fetch appointments for a user like this:
/user/:userId/appointments
How should the url look like if I want to get appointments for multiple users?
should it be:
/appointments?users=1d1,1d2..
Thanks,
Chris.
Collections are a resource so /appointments is fine as the resource.
Collections also typically offer filters via the querystring which is essentially what users=id1,id2... is.
So,
/appointments?users=id1,id2
is fine as a filtered RESTful resource.
Another way of doing that, which can make sense depending on your server architecture/framework of choice, is to repeat the same argument over and over again. Something like this:
/appointments?users=id1&users=id2
In this case I recommend using the parameter name in singular:
/appointments?user=id1&user=id2
This is supported natively by frameworks such as Jersey (for Java). Take a look on this question for more details.
I think it's a better practice to serialize your REST call parameters, usually by JSON-encoding them:
/appointments?users=[id1,id2]
or even:
/appointments?params={users:[id1,id2]}
Then you un-encode them on the server. This is going to give you more flexibility in the long run.
Just make sure to URLEncode the params as well before you send them!
This worked for me.
/users?ids[]=id1&ids[]=id2
/appointments?users=1d1,1d2..
is fine. It's pretty much your only sensible option since you can't pass in a body with a GET.
Instead of using http GET, use http POST. And JSON. Or XML
This is how your request stream to the server would look like.
POST /appointments HTTP/1.0
Content-Type: application/json
Content-Length: (calculated by your utility)
{users: [user:{id:id1}, user:{id:id2}]}
Or in XML,
POST /appointments HTTP/1.0
Content-Type: application/json
Content-Length: (calculated by your utility)
<users><user id='id1'/><user id='id2'/></users>
You could certainly continue using GET as you have proposed, as it is certainly simpler.
/appointments?users=1d1,1d2
Which means you would have to keep your data structures very simple.
However, if/when your data structure gets more complex, http GET and without JSON, your programming and ability to recognise the data gets very difficult.
Therefore,unless you could keep your data structure simple, I urge you adopt a data transfer framework. If your requests are browser based, the industry usual practice is JSON. If your requests are server-server, than XML is the most convenient framework.
JQuery
If your client is a browser and you are not using GWT, you should consider using jquery REST. Google on RESTful services with jQuery.
I know it might sound silly but how do I determine a website supports JSON?
I know what/how JSON use for a long time, but I do not know how could I technically know whether a
server has json support. Do I need to manually request json file to check whether it suppports or not?
Any comment would be appreciated !
You can check what is the content type of server response, usually this is
application/json
(1) "Websites" don't really serve up JSON; the notation syntax isn't really meant for page rendering, it's made for data transmission.
(2) What oftentimes serves up JSON are APIs (like those of Facebook and StackExchange). These APIs usually use HTTP GET, POST, PUT, and DELETE methods to interact with services they provide, and (sometimes optionally) transmit the bulk of the payload data in JSON format.
(3) It doesn't really make sense to ask where to get JSON. If you'd simply like to play with some JSON for educational purposes, Python, PHP, Javascript, etc. all have great built-in support. What you ought to be looking for are the services that you'd like to utilize, and whether or not they support JSON. If the service is new, or popular, and has relatively good API support, odds are it will work with JSON.
As far as I know, JOSN is just a format, like XML. You can create JSON page by hand, or use easy functions in a lot of the major coding languages.
Example: PHP does this easily with json_encode(String) json_decode(String). So, as far as my knowledge goes, every server / website can support JSON, though some might not have the updated PHP or whatever coding language you may be doing, to support easy implementation of JSON.
If a iphone app needs to communicate with a server, is xml the best route in most cases?
how hard is it to parse xml in obj-c?
It really depends on the type of data you wish to exchange, but XML will at the very least be able to handle any complexity of data structure you require. (If you only want to exchange a minimal amount of information, you might want to consider JSON that said.)
There are quite a few XML parsers available for Objective-C, most of which are discussed on this existing question: Navigating XML from Objective-C
Finally, there's a great blog post on Ray Wenderlich's web site that discusses the various XML parsers with a view to speed/memory footprint which might be important if you're parsing a large amount of data.
Depends on what is beeing transmitted.
That said I use JSON for 90% of my server to app communication. Easy to parse as libraries are readily available.
Nope. Not hard. But when it comes to APIs it seems many prefer JSON.
JSON is easier to work with than XML, regardless of parser used. Lots of server side people will understand JSON quite well because of the need to use it to work with Javascript.
The iPhone JSON parser I'd look at using first is YAJL.
I would either go with XML or JSON ( http://www.json.org/ ).
It's very easy to parse XML on the iPhone. There are quite a few XML parsers out there based on your preference. For a DOM parser you can use TBXML, otherwise Apple's built-in NSXMLParser does the job.
I use JSON, which is a great (and popular) solution for your server as well. Try out SBJSON for a good obj c library:
http://code.google.com/p/json-framework/
We are going to set up a solution where the iPhone is requesting data from the server. We have the option to decide what kind of solution to put in place and we are not sure about which way to go.
Regarding SOAP I think I have the answer, there are no really stable solution for doing this (I know there are solutions, but I want something stable).
How about REST?
Or is it better to just create our own XML? It's not going to be so complicated reguest/respons-flow.
Thanks in advance!
I've created an open source application for iPhone OS 3.0 that shows how to use REST & SOAP services in iPhone application, using XML (using 8 different iPhone libraries), SOAP, JSON (using SBJSON and TouchJSON), YAML, Protocol Buffers (Google serialization format) and even CSV from a PHP sample app (included in the project).
http://github.com/akosma/iPhoneWebServicesClient
The project is modular enough to support many other formats and libraries in the future.
The following presentation in SlideShare shows my findings in terms of performance, ease of implementation and payload characteristics:
http://www.slideshare.net/akosma/web-services-3439269
Basically I've found, in my tests, that Binary Plists + REST + JSON and XML + the TBXML library are the "best" options (meaning: ease of implementation + speed of deserialization + lowest payload size).
In the Github project there's a "results" folder, with an Excel sheet summarizing the findings (and with all the raw data, too). You can launch the tests yourself, too, in 3G or wifi, and then have the results mailed to yourself for comparison and study.
Hope it helps!
REST is the way to go. There are SOAP solutions, but given that all people end up doing with SOAP can be done with RESTful services anyway, there's simply no need for the overhead (SOAP calls wrap XML for data inside of an XML envelope which must also be parsed).
The thing that makes REST as an approach great is that it makes full use of the HTTP protocol, not just for fetching data but also posting (creating) or deleting things too. HTTP has standard messages defined for problems with all those things, and a decent authentication model to boot.
Since REST is just HTTP calls, you can choose what method of data transfer best meets your needs. You could send/receive XML if you like, though JSON is easier to parse and is smaller to send. Plists are another popular format since you can send richer datatypes across and it's slightly more structured than JSON, although from the server side you generally have to find libraries to create it.
Many people use JSON but beware that it's very finicky about parsing - mess up a character at the start of a line, or accidentally get strings in there without escaping "'" characters and there can be issues.
XML Property-lists (plist) are also a common way to serialize data in Cocoa. It is also trivial to generate from other languages and some good libraries exist out there.
You are not saying how complex your data structures are and if you actually need state handling.
If you want to keep your network traffic to a minimum, while still keeping some of the structured features of XML, you might have a look at JSON. It is a very light weight data encapsulation framework.
There are some implementations available for iPhone, for instance TouchJSON
Claus
I would go with simple HTTP. NSURLConnection in the Cocoa libraries make this pretty simple. Google Toolbox for Mac also has several classes to help parsing URL-encoded data.
I think it's obvious that REST is the new king of servers communication, you should definitely use REST, the questions should be what REST methodology you should use and what coding language, in my post I present few very simple implementations for REST servers in C#, PHP, Java and node.js.