I am in the process of creating and negotiating a specification for some new functionality on a web app. The new functionality includes enabling users to send PDF files along with some other data (a name, a creation date, a city, etc.) to a server on a different domain. So it is really multipart data, binary and plain text mixed together.
What would be your preferred way of doing this, knowing that
the PDF files will not exceed 5 MB and the plain text data fields are very small
our development time is limited to about 10 days
The developer of the receiving application is in favour of SOAP (not sure if he wants to encode the file or send it as an attachment), because it is tried and tested in their application. I think I am in favour of using just plain POST, because it's simple and doesn't require additional protocols. My argument against SOAP would be that our app is written in Java and theirs in .NET and I don't want to run into compatibility issues with SOAP.
I have little experience with web services, so any arguments against or in favour of these technologies will be appreciated.
The reason you are being downvoted is that you have shown little to no effort.
There are no compatibility issues with java to .NET for the most part. Additionally if your vendor(developer) has proven success with a method then why are you going to spend money developing an entirely separate solution which will have to be maintained specifically for you.
It sounds like you are just spewing rhetoric because you wish to win an argument rather than be correct.
Related
I am in the process of scoping the development of an iPhone app for a client. Among other things, the app will allow users to browse through and place orders on specific (tangible) products.
The client has a website that currently does a similar thing and due to their limited budget and the fact that the website runs on a third-party proprietary platform which they have no control over, we are investigating possible alternatives to building a web service.
On the website, user registration and authentication, as well as order placing is done through POST requests via secure HTTP. The response is always a formatted HTML page which will contain strings indicating whether the request was successful or not, and if there was an error, what the error is etc.
So provided I can replicate the POST requests on the phone, and parse the HTML responses to read the results of each request, do you think this is an acceptable alternative to building a web service to handle this?
Apart from the possibility of pages changing (which we can manage) and the fact that I will probably have to download and parse a relatively large HTML response, are there any other drawbacks to this solution and is there anything else that I might be missing?
Many thanks in advance for your thoughts.
Cheers,
Rog
You could create an intermediary server that will communicate with the client server, and on it expose some REST web services with json (small overhead and easy to handle) responses that will be consumed by the iPhone app.
So, you're going to parse HTML and formulate POSTs off a third-party server, and pray that they don't even so much as rename a form field.
Your question is in two parts:
Do I think that a miracle is an acceptable solution? I don't.
Do I think that aside from the fact a miracle is required, are there any other drawbacks? None that I can think of.
You didn't ask, but this is a terrible course of action. Two suggestions.
I spy an assumption that the providers of the third-party platform aren't interested in enabling third-party applications by providing an API. They have a very good business reason for this, which is that it promotes platform lock-in. Reach out to their support department and have a talk with them.
You have to sell the client on building an intermediary web service. To at least try to mitigate the damage that changes on this third-party platform can do to your app, I recommend that you build and operate a proxy that receives requests from your applications, and proxies them over to the third-party platform. You should build into this client-server protocol a means for returning "we are in maintenance mode, go away" messages to apps, for that inevitable day when the third-party server changes something that breaks your app (they swapped the billing and shipping address pages, for instance) and you have to rush through an update through Apple to deal with it.
The proxy could be written in something more flexible and easy to bash stuff out in, such as PHP, Python, Perl, or Ruby. It could be hosted at Amazon in a micro instance.
p.s. This question is inappropriately tagged objective C.
HTML is the worst because of parsing (1-2secs per page), memory, and changes, but you already know that. Check in advance that ALL the data you need is exposed on the HTML.
If you use an intermediary server you are moving work elsewhere and you have another server to maintain. I would only do that if memory is an issue. Check How To Choose The Best XML Parser for Your iPhone Project for memory/performance/xpath support. libxml2 is a good option, but it depends on your needs. And maybe you'll want to check ASIHTTPRequest features before using the SDK.
I think utilising the web language of JSON would contribute to the diminishing of the parsing time. By building a REST service that, when sent a GET request, returns the correct information for easy sorting, you could then display the output a lot faster than that of parsing straight HTML.
I prefer JSON over XML, but everyone has their personal preference. You should look at a few very good libraries that are built specifically for parsing purposes of both XML and JSON.
For XML I recommend using the inbuilt libxml parser. Albeit, this can sometimes deem very difficult to use. A simple Google search will bring up a heap of results that relate specifically to what parser should be used depending on what task is to be completed.
As for a JSON parser, I recommend SBJSON. I am currently using it one of the biggest projects I have undertaken and it is definitely working perfectly for my use.
If you need a good way to connect to a RESTful web service, you should try LRResty.
Don't go for a parsing solution on the iPhone for 4 reasons:
Server can change their design and break your application (AppStore submition is long) + They can also detect that the request are sent from an application based on user agent which you have to update the application to change it.
Some of the requests might be made thru Javascript so you not only have to parse (X)HTML but also Javascript request (which can be in the form of XMLHttpRequest, but don't have to)
Long term evolution of the mobile market : maybe your client want (or will want) an application for android, Blackberry, Bada OS (Samsung), Symbian (Nokia/ OVIStore), Java Mobile or Windows Phone 7?
Of course network traffic, Memory and CPU needed to parse HTML (look the time it takes to the browser to do it?)
Regarding the traffic, if the application will not have a huge traffic you can home-host your proxy. Or you can find some provider to host it for you. I guess you won't need more than a couple of Megabytes of storage but maybe traffic. For less than 100€/year you can find some with unlimited traffic (like OVH Pro plan or Infomaniak). But if you want to go Java have a look at Google App Engine : you pay only if your traffic is important and if your application generate many CPU Cycles. If not : you don't have to pay. And it's hosted on Google server : reliable.
If the client is open, you could consider the paypal API.
I would like to build an XML over HTTP provisioning interface using Zend Framework. Should Zend_XmlRpc_Server be used for this purpose? If so, can you recommend any guides on using it? (Specifically the part retrieving incoming XML and parsing it.)
What kind of service is it? - will you send binary data or rather short texts? Will all clients be in PHP mostly or you are foreseeing a wide range of clients?
Usually if you're doing a web-based small service, REST will do the trick, it's easy to develop and consume, even by plain JS frontends, such as jQuery.
If it's something more complex, you can't go wrong with SOAP, though it's a bit complex in developing. Make sure you arm yourself with SoapUI
XmlRPC has some limitations, especially sending binary data. There's some thorough comparison to have a look at this blog
I mean, true true interop: from Java to .NET, from PHP to Java, etc.
I'm asking because our powers that be want us to implement public-facing API with SOAP web services, and I'm trying to make a strong point in favor of RESTful XML/JSON API.
Their reasoning is very much brainwashing-induced:
SOAP is a standards-based protocol (let alone one of our devs has spend last 4 days buried in XML configuration and custom security token serializers trying to somehow bend WCF client so that it would call WSE 3.0 service and it produces all sorts of obscure errors),
SOAP is secure (but business-wise we don't need neither encryption nor digital signatures - HTTP over SSL will be more than enough)
Finally, SOAP is interoperable, and this seems to be the top selling point for them (the whole point of this question)
To reiterate: is SOAP truly interoperable? Your real-world war stories will be excellent.
As long as you stick to WS-I-based SOAP standards, then interop is usually pretty easy. WS-I was designed to address to initial interop problems that early SOAP implementations suffered from.
The problems tend to crop up when using pre-WS-I web services (e.g. rpc-encoded stuff), or when using the fancy security extensions that the likes of WCF makes a big deal of. Those get complex, and hard to debug when they go wrong.
Yes, for the most part it is, though sometimes it can be a battle. I have a number of standards based soap services and some languages/libraries seem to be easier than others.
However, all is not happy in SOAP land. One particularly naughty library (Apache Axis), by default compiles a copy of the WSDL into its stubs....which is not odd in of itself because .net does the same thing....but the problem is that it also validates the WSDL for any changes at all. And if a change is detected it throws up.
So lets say you have a create user method and you add middle initial 5 months down the road. You will break the service for all consumers using Axis...even if middle initial is NOT required and the service could care less if you sent it. So at our place, we have to send out messages to clients months in advanced of adding any optional params so they can hire their contractors again to just recompile the WSDL on release night.
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.
I have a fair bit of experience working with the iPhone SDK. I have a couple fully developed apps including a utility application for tracking data and a board game. I would consider myself a novice on the iPhone SDK. I also have no issues with reviewing documentation and examples for hours until I understand something, as long as the documentation exists and makes sense.
I am not however an expert at XML documents and parsing attributes and creating documents. I have written in the past PHP code to access web services and complete transactions via SOAP XML messaging. I need to do a similar application using iPhone SDK. Here is what I need.
1) Create XML messages to send to a SOAP service
2) Receive XML messages from a SOAP service
3) Parse the XML response messages into a custom object
All of the URL and SOAP part is relatively straight forward. Where I start to get discouraged is the area of creating and parsing the XML messages. Using PHP these tasks are very simple as the language has built in SOAP clients and you can easily class map objects to SOAP messaging and the heavy lifting of the XML processing is just taken care of automatically. I have considered writing a proxy PHP service and simplifying what is needed on the iPhone side but this just complicates what I want and adds a dependency on another app to work in conjunction with the web service I'm accessing.
It seems that in the iPhone SDK or objective-c in general you have to be a pro at the construction and the parsing of XML messages on your own. I am really discouraged at the idea of creating tons of custom code to parse each message element by element. I've taken a small look at TouchXML / KissXML and I am not thinking they are what I need.
The real key objective here is that I want to easily receive an XML message and some how get the elements and their values copied over to an object. How can this be done without hours of writing parsing classes and understanding all of the guts of creating XML documents?
I have used Matt Gallagher's XPathQuery to great success on the iPhone. It's simple and straight-forward.
I've found, though, that the messages I have need to parse are drastically simpler than what XML (and even his simplified parser) is capable of. I've modified his source to return a data structure that's much easier to work with -- instead of having keys a bunch of keys (nodeName, nodeContent, nodeAttributeArray, attributeName, ...) for each node, I simply create nested arrays and dictionaries with the node name as the key and the content as the object directly. I completely ignore attributes, and I only use arrays if there's more than one node with the same name. Here's that code. Note that it's only been tested on the XML that I care to work with. :)
Edit: whoops, I just realized you're also looking for XML creation. This just does parsing. I'll leave it here as a partial answer.
It seems like what you really want is this:
http://code.google.com/p/wsdl2objc/
As it will create objects for you from a WSDL, and provide support code to send/receive them.
However what is mostly happening, is that people are not using SOAP for mobile web services, but instead are going to RESTFUL approaches.
That includes posting form data in HTTP POST requests or querying via GET, then getting back either JSON or plists which turn into dictionaries (JSON is more widely understood by server developers BUT you have to be more careful to correctly define the structures being passed, since you can do things like have a dictionary with the same key repeated... plists are more robust in that you can't really build anything "wrong" but is less standard on the server side).
If you have to use SOAP though, WSDL2ObjC is probably going to save you a lot of mapping.