I have a requirement where I have large amount of data(in form of pdf,images,doc files) on server which will be distributed to many users. I want to pull these file using web services along with their meta-data. I will be getting the files in bytes. I am confused in which type of web service will be more secure, easy to parse? Which one is easy to implement on iPhone client?
I know REST is simpler but I read somewhere that it is not suitable for distributed environment. At the same time SOAP is too heavy for mobile platform.
I have searched many sites describing how REST is easier and how SOAP is secure. I got confused about which one to use?
Also about the kind of response, which will be better JSON or XML for my requirement?
For your requirements JSON will be the best kind of response because it is way smaller than XML (More than 50% smaller in many tests). You can use SBJSON (https://github.com/stig/json-framework/) to parse it easily on iOS.
Concerning REST or SOAP, the last one is indeed really heavy for mobile platform and not so easy to implement. SOAP requires XML too and cannot be used with JSON. Whereas with REST you can use JSON or XML and easily implement it on iOS with RESTKit (http://restkit.org/), for security you can use an SSL connection with HTTPS and a signed certificate.
The only advantage of SOAP is the WSDL (Webservice specification) which made your webservices really strong.
Unless you have a specific requirement to pull the file data and the metadata in the same response, you might consider just pulling down the file with a regular HTTP GET. You can get decent security with HTTPS and Basic Auth or client certificates. I would then include a Link header pointing to the metadata for your file, as in:
Link: </path/to/metadata>;rel=meta
In particular, this lets you have separate caching semantics for the file itself and for its metadata, which is useful in the common case where the files are much larger than their metadata and where metadata can change without file contents changing.
Related
this is a general 'what technologies are available' question.
My company provides a web application with a RESTful API. However, it is too slow for my needs and some of the results are in an awkward format.
I want to wrap their restful server with a proxy/adapter server, so when you connect to the proxy you get the RESTful API I wish the real one provides.
So it needs to do a few things:
passthrough most requests
cache some requests
do some extra requests on the original server to detect if a request is cacheable
for instance: there is a request for a field in a record: GET /records/id/field which might be slow, but there is a fingerprint request GET /records/id/fingerprint which is always fast. If there exists a cache of GET /records/1/field2 for the fingerprint feedbeef, then I need to check the original server still has the fingerprint feed beef before serving the cached version.
fix headers for some responses - e.g. content-type, based upon the path
do stream processing on some large content, for instance
GET /records/id/attachments/1234
returns a 100Mb log file in text format
remove null characters from files
optionally recode the log to filter out irrelevant lines, reducing the load on the client
cache the filtered version for later requests.
While I could modify the client to achieve this functionality, such code would not be re-usable for other clients (different languages), and complicates the client logic.
I had a look at whether clojure/ring could do it, and while there is a nice little proxy middleware for it, it doesn't handle streaming content as far as I can tell - the whole 100Mb would have to be downloaded. Also it doesn't include any cache logic yet.
I took a look at whether squid could do it, but I'm not familiar with the technology, and it seems mostly concerned with passing through requests rather than modifying them on the fly.
I'm looking for hints where I might find the correct technology to implement this. I'm mostly language agnostic if learning a new language gets me access to a really simple way to do it.
I believe you should choose a platform that is easier for you to implement your custom business logic on. The following web application frameworks provide easy connectivity with REST APIs, and allow you to create a web application that could work as a REST proxy:
Play framework (Java + Scala)
express + Node.js (Javascript)
Sinatra (Ruby)
I'm more familiar with Play, of which I know it provides utilities for caching you could find useful, and is also extendable by a number of plugins.
If you are familiar with Scala, you could have a also have a look at Finagle. It is a framework build be Twitter's infrastructure team to provide protocol-agnostic connectivity. It might be an overkill for REST to REST proxy, but it provides abstractions you might find useful.
You could also look at some 3rd party services like Apitools, which allows to create a proxy programmatically (in lua). Apirise is a similar service (of which I'm a co-founder) that intends to do provide similar functionalities with a user-friendly UI.
Beeceptor does exactly what you want. It plugs in-between your web-app and original API to route requests.
For your use-case of caching a few responses, you can create a rule. That way it shall not hit the original endpoint.
The requests to original APIs can be mocked, and you can inspect response
You can simulate delays.
(Note: it is a shameless plug, I am the author of Beeceptor and thought it should help you and other developers.)
https://github.com/nodejitsu/node-http-proxy is looking useful - although I don't yet know if it can stream process for transcoding.
This is one very common question asked again and again on stack overflow and I read so many answers about this but I am still bit confused.
I need to call the webservices from iPhone sdk.
Here are my questions:
I am not clear what response SOAP or REST return.Is there anything specific that if response is XML then we should use REST and if JSON we should use SOAP?
What is the role of ASIHTTP with SOAP and REST?
If I am getting XML response as
<oproduct>
<iid>113133791</iid>
<icategoryid>270</icategoryid>
<imerchantid>1547</imerchantid>
<iadult>0</iadult>
<sname>The Ashes / 1st Test - England v Australia - Day 1</sname>
<sawdeeplink>http://www.acbcd.com/pclick.php?p=113133791&a=111402&m=1547&platform=cs</sawdeeplink>
<sawthumburl>http://images.abcdd.com/thumb/1547/113133791.jpg</sawthumburl>
<fprice>69.99</fprice>
</oproduct>
Do I need to parse it by hand? or how do I handle XML response?
I got so many articles about REST and SOAP but no proper code to understand it.
I would be grateful for any help regarding these questions.
SOAP - "Simple Object Access Protocol"
SOAP is a method of transferring messages, or small amounts of information, over the Internet. SOAP messages are formatted in XML and are typically sent using HTTP (hypertext transfer protocol).
So SOAP has a standard how a message has to be sent.
Each soap web service can be defined with a WSDL(Web Service Definition Language) which is kind of a schema for the SOAP XML transferred.
There are many tools available to convert WSDL(your webservice definition) to native code.
One of the tool available for ObjC is Sudz-C (http://sudzc.com/) which convert the WDSL of any webservice to ObjC code to access the Web service.
Rest - Representational state transfer
Rest is a simple way of sending and receiving data between client and server and it don't have any much standards defined , You can send and receive data as JSON,XML or even a Text. Its Light weighted compared to SOAP.
To handle Rest in iOS there are many tools available, I would recommend RestKit http://restkit.org/, for handling XML and JSON both.
I would suggest you to go with Rest for mobile development, since its light weight
(Simple example, People correct me If I am wrong)
Ok, so you have a few different questions here:
REST is a way of accessing the web service. SOAP is an alternative way of accessing the web service. REST uses query string or URL format whereas SOAP uses XML. JSON and XML are two different ways of sending back data. SOAP and XML are usually associated with each other. For mobile apps, REST/JSON is usually the way to go. Easier to implement and maintain, far more telegraphic, etc.
ASIHTTP, as Bill notes, is a wrapper. There are other choices that do similar things depending on what you need. If you are using REST/JSON then NSURLConnection + SBJSON might do the trick, I like it personally.
If your SOAP service has an available WSDL you can use wsdl2objc to automatically build the code for your parsing and fetching. If it is a JSON service or no WSDL is available, I would recommend using SBJSON and simply parsing in the following way:
for (id jsonElement in repsonse) {
self.propertyA = [jsonElement valueForKey:#"keyA"];
self.propertyB = [jsonElement valueForKey:#"keyB"];
}
Hope that helps!
1) SOAP responses must be XML, and to return other formats you need to either embed them in the response XML (inefficient) or use SOAP attachments (difficult). SOAP responses are contained in a soap envelope tag, and there is usually an associated wsdl. If the XML you show is all you're getting, then it may not be a SOAP service. I see links in the XML so that is a good sign that they had REST in mind.
2) I haven't heard of ASIHTTP. A quick google, and it looks like its a third party library that wraps the http interfaces in iOS. It looks like you would use that to help you make the http requests, although I would suggest that it might not be necessary; you should evaluate using the http libraries directly.
3) You need to parse it somehow. You can do it by hand, but that is generally a really bad idea. XML can come in many forms and still have the same meaning, and if you don't support all forms your application could break in the future if the web service provider began to format their XML differently, even if its semantics were the same. You would use an XML api to read the XML. The DOM api will read it into a tree form for you, and you can use XPath to extract information out of the tree.
I've tried to read about what RESTful webservices from Wikipedia etc but I must admit I don't get it. There is a film in which Denzell Washington says "explain it to me like I'm a 5 year old". Can someone do that for me regarding RESTful services?
Bonus points if you know the name of the film.
When I first started with REST, I too had some difficulty getting the "big picture", despite all the documentation out there. Anyways, here's my brief take on REST:
REST is an architectural style for building web services.
REST is built on top of HTTP. Your web service exposes Resources in the form of URIs. Your service allows clients to act upon your service using the standard HTTP verbs (GET=read the resource, POST=create the resource, PUT=update the resource, DELETE=delete the resource).
REST has gained significant momentum in the past few years due largely to (a) Its simplicity over other styles like SOAP. (b) The ubiquity of HTTP. Because HTTP is a time-tested standard, most languages have build-in or 3rd-party HTTP support. You cannot say the same thing about SOAP.
Because REST is a style and not a strict protocol/specification, there is lots of room for interpretation. Many public services that call themselves "REST" do not follow the style to the letter.
RESTful services are services that transfer state represntationally, hence the name REpresentational State Transfer. What this actually means is that data is passed in a declarative manner, which is to say, you get what you ask for.
REST is different from SOAP in that it's not a protocol, and there's no formal specification. SOAP was created to simplify data transfer between applications by using a common interface to access functionality remotely. Unfortunately, to work generally, SOAP is quite complicated, and making SOAP requests is not very straight-forward, requiring XML parsing and generation.
Instead, REST relies on Hyper Text Transfer Protocol (HTTP) to do the heavy lifting. Webservers and server scripts are already built around working within HTTP. To make a request using REST is as simple as a URL request, such as visiting a webpage. The API for a RESTful service can reuse any of HTTP's methods and status codes to signal any errors. Instead of accessing data that's stored in a database through fancy queries and special code, RESTful services allow access that's more similar to a standard filesystem.
The key part of RESTful services, is the declarativeness. A request to GET /widgets/109340 is likely going to get you the data for the widget with an id of 109340. I say "likely" because there's no guarantee. It's up to the implementor. The point is that you can glance at the REST request and know what you expect to be returned. With SOAP, it's much harder to tell whether you have a syntax error.
If /widgets/109340 doesn't exist, instead of passing back a message body, with some specific value to state that the content exists, the server can return a 404 Not Found code, and the user will know that the particular ID doesn't exist. If 403 is returned, the user will know that the item exists, but that they don't have permissions to access it. These request response codes are already supported by programs that make URL requests, because they're common to all servers. This makes REST requests much more resilient.
REST is also flexible on the output format, /widgets/109340 could return a JSON object, but there's no reason it can't return binary data, HTML, XML, SVG, Video, or any other data format. A CDN could use a REST API to serve up versioned content which may or may not be stored on the filesystem: GET /jQuery/1.0.0, GET /jQuery/1.7.1, and GET /jQuery/latest are all RESTful requests.
I'm going to assume you understand what Simple Object Access Protocol (SOAP) is
I do not have much experience coding systems dealing with web-services. Please help me in solving following confusion.
One of my clients want me to build an iPhone App that had native UI controls but deals extensively with Web Services. Right from authenticating the user into a network to loading a list of users or anything related in the app will need to talk to a web service.
They have web services deployed on .NET on the server side and already have required data in SOAP web service. By doing some basic research on the web it seems that dealing with SOAP from an iPhone app could be messy and affect performance.
The client is ready to make the data available in from of JSON or plain XML data. I am not sure which one would be a better option? The data could range from few tens to few hundreds of rows only.
Can someone please point me how can I do a comparative study in short period of time (3-4 days) even if it takes for me to learn about the SOAP, XML, JSON and REST web services. Is this even possible or should I just go with some expert advice? - Waiting for expert advice :)
Thanks
XML and JSON are data interchange formats. JSON is generally considered easier to work with, although a good library should make both palatable.
REST is an architectural style; it is the architectural style that HTTP is designed to support.
SOAP is a protocol for implementing web services, and it does not follow the REST architectural style; it's more of an Remote Procedure Call style.
I dislike SOAP because it forces you to rely on tools to manage many of its facets. If your tools happen to work differently than the tools used by the other end, then it becomes extremely painful.
I recommend reading RESTful Web Services for a general overview of REST, and why it's "better" than SOAP.
I don't have any good resources for SOAP, or anything iPhone specific.
RESTFul webservices can return responses in XML or in JSon, the option of using such service is better than soap for iphone because of the overhead involved with soap as you mentioned. Basically when u get responses in xml or json its just some text that you need to parse. I would recommend going with Json as there are json parser libraries for iphone out there already and its very simple to use...Here is a tutorial for using the json parser and parsing your responses, Json tutorial...hope it helps
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.