Latest News

    • Web Services Architecture – When to Use SOAP vs REST

      23 / 13 Oct 2014

      SOAP (Simple Object Access Protocol) and REST (Representation State Transfer) are popular with developers working on system integration based projects. Software architects will design the application from various perspectives and also decides, based on various reasons, which approach to take to expose new API to third party applications. As a software architect, it is good practice to involve your development team lead during system architecture process.   This article, based on my experience, will discuss when to use SOAP or REST web services to expose your API to third party clients.   Web Services Demystified Web services are part of the Services Oriented Architecture. Web services are used as the model for process decomposition and assembly. I have been involved in discussion where there were some misconception between web services and web API.   The W3C defines a Web Service generally as:   A software system designed to support interoperable machine-to-machine interaction over a network.   Web API also known as Server-Side Web API is a programmatic interface to a defined request-response message system, typically expressed in JSON or XML, which is exposed via the web – most commonly by means of an HTTP-based web server. (extracted from Wikipedia)   Based on the above definition, one can insinuate when SOAP should be used instead of REST and vice-versa but it is not as simple as it looks. We can agree that Web Services are not the same as Web API. Accessing an image over the web is not calling a web service but retrieving a web resources using is Universal Resource Identifier. HTML has a well-defined standard approach to serving resources to clients and does not require the use of web service in order to fulfill their request.   Why Use REST over SOAP Developers are passionate people. Let's briefly analyze some of the reasons they mentioned when considering REST over SOAP:   REST is easier than SOAP I'm not sure what developers refer to when they argue that REST is easier than SOAP. Based on my experience, depending on the requirement, developing REST services can quickly become very complex just as any other SOA projects. What is your service abstracting from the client? What is the level of security required? Is your service a long running asynchronous process? And many other requirements will increase the level of complexity. Testability: apparently it easier to test RESTFul web services than their SOAP counter parts. This is only partially true; for simple REST services, developers only have to point their browser to the service endpoints and a result would be returned in the response. But what happens once you need to add the HTTP headers and passing of tokens, parameters validation… This is still testable but chances are you will require a plugin for your browser in order to test those features. If a plugin is required then the ease of testing is exactly the same as using SOAPUI for testing SOAP based services.   RESTFul Web Services serves JSON that is faster to parse than XML This so called "benefit" is related to consuming web services in a browser. RESTFul web services can also serve XML and any MIME type that you desire. This article is not focused on discussing JSON vs XML; and I wouldn't write any separate article on the topic. JSON relates to JavaScript and as JS is very closed to the web, as in providing interaction on the web with HTML and CSS, most developers automatically assumes that it also linked to interacting with RESTFul web services. If you didn't know before, I'm sure that you can guess that RESTFul web services are language agnostic. Regarding the speed in processing the XML markup as opposed to JSON, a performance test conducted by David Lead, Lead Engineer at MarkLogic Inc, find out to be a myth.   REST is built for the Web Well this is true according to Roy Fielding dissertation; after all he is credited with the creation of REST style architecture. REST, unlike SOAP, uses the underlying technology for transport and communication between clients and servers. The architecture style is optimized for the modern web architecture. The web has outgrown is initial requirements and this can be seen through HTML5 and web sockets standardization. The web has become a platform on its own right, maybe WebOS. Some applications will require server-side state saving such as financial applications to e-commerce.   Caching When using REST over HTTP, it will utilize the features available in HTTP such as caching, security in terms of TLS and authentication. Architects know that dynamic resources should not be cached. Let's discuss this with an example; we have a RESTFul web service to serve us some stock quotes when provided with a stock ticker. Stock quotes changes per milliseconds, if we make a request for BARC (Barclays Bank), there is a chance that the quote that we have receive a minute ago would be different in two minutes. This shows that we cannot always use the caching features implemented in the protocol. HTTP Caching be useful in client requests of static content but if the caching feature of HTTP is not enough for your requirements, then you should also evaluate SOAP as you will be building your own cache either way not relying on the protocol.   HTTP Verb Binding HTTP verb binding is supposedly a feature worth discussing when comparing REST vs SOAP. Much of public facing API referred to as RESTFul are more REST-like and do not implement all HTTP verb in the manner they are supposed to. For example; when creating new resources, most developers use POST instead of PUT. Even deleting resources are sent through POST request instead of DELETE.   SOAP also defines a binding to the HTTP protocol. When binding to HTTP, all SOAP requests are sent through POST request.   Security Security is never mentioned when discussing the benefits of REST over SOAP. Two simples security is provided on the HTTP protocol layer such as basic authentication and communication encryption through TLS. SOAP security is well standardized through WS-SECURITY. HTTP is not secured, as seen in the news all the time, therefore web services relying on the protocol needs to implement their own rigorous security. Security goes beyond simple authentication and confidentiality, and also includes authorization and integrity. When it comes to ease of implementation, I believe that SOAP is that at the forefront.   Conclusion This was meant to be a short blog post but it seems we got to passionate about the subject.   I accept that there are many other factors to consider when choosing SOAP vs REST but I will over simplify it here. For machine-to-machine communications such as business processing with BPEL, transaction security and integrity, I suggest using SOAP. SOAP binding to HTTP is possible and XML parsing is not noticeably slower than JSON on the browser. For building public facing API, REST is not the undisputed champion. Consider the actual application requirements and evaluate the benefits. People would say that REST protocol agnostic and work on anything that has URI is beside the point. According to its creator, REST was conceived for the evolution of the web. Most so-called RESTFul web services available on the internet are more truly REST-like as they do not follow the principle of the architectural style. One good thing about working with REST is that application do not need a service contract a la SOAP (WSDL). WADL was never standardized and I do not believe that developers would implement it. I remember looking for Twitter WADL to integrate it.   I will leave you to make your own conclusion. There is so much I can write in a blog post. Feel free to leave any comments to keep the discussion going.

    • Liferay and AngularJS Made Simple: Connecting AngularJS to a Backend with REST and JSON

      24 / 01 Oct 2014

    • Big Data Architecture Best Practices

      7 / 25 Sep 2014

    • 4 Reasons Football Teams Should Use Big Data and IoT

      177 / 17 Sep 2014

    • Technology news about start-ups big data cloud IoT Liferay

      11 / 08 Sep 2014

    • I Got hacked today and never use GoDaddy.com for hosting

      24 / 31 Dec 2012

    • PaaS Cloud - The Rise of The Developer Entrepreneur

      66 / 22 May 2012

    • Developers should not believe the HTML5 hype

      30 / 06 May 2012

    • 5 Things all Java developer should know when developing for the cloud

      623 / 30 Apr 2012

    • The traveling robot problem

      6 / 25 Apr 2012

    • Primefaces Mobile - Weather App Example

      503 / 20 Apr 2012

    • Parachutist Dilemma - a parallel programming problem

      5 / 19 Apr 2012

    • Cloud computing vs Open Source - Most CIO cannot tell the difference

      8 / 20 Feb 2011

    • Apple vs Geeks - is this the end of a love affair?

      5 / 12 Apr 2010

    • Facebook Patents RSS-like Technology - Is That a Joke?

      35 / 26 Feb 2010

    • Will Oracle really make NetBeans the BEST IDE for Java

      15 / 31 Jan 2010

    • Google Analytics vs Woopra

      3 / 05 Jan 2010

    • Happy New Year Techies!!!

      7 / 31 Dec 2009

    • Dummies Guide to GWT and OpenID - with example code

      211 / 23 Dec 2009

    • Firefox IE8 Chrome Opera Safari - best browser for Java?

      10 / 17 Dec 2009
Monday, 12 April 2010
Home > Untagged Apple vs Geeks - is this the end of a love affair?

Apple vs Geeks - is this the end of a love affair?

This isn't news anymore but I wanted to wait for more light on the subject before I made any comments. Apple vs Adobe is actually an understatement. Actually, this is no surprise as Apple has always been a control freak. I mean, just take a look around you. How many PCs do you see running Apple MacOS which has not been branded by Apple Inc? Anybody trying to build a PC which runs their OS gets sued. Seriously, Microsoft may be evil but they have created an economy which in Steve Jobs world would have never existed. History is about to repeat itself; Apple Inc introduces a great idea/ products but would eventually become a niche player (well, only time will tell!!!).

I don't actually believe that real geeks use MacOS; Linux or if you work for a company this would MS Windows. Let's face it, Apple PCs (or Book, G5 or whatever) look very good on the receptionist desk and that's about it. Steve doesn't want you to innovate, he wants you to follow him to whatever **** he introduces (ipad anybody?).

Let me get back to the subject. Being software developer and I have invested time and money to build knowledge and skills. I cannot possibly learn every single programming language and therefore would welcome any tools that help me to cross-compile my code. I am not even a flash developer and seriously I don't care less about what they do. But the new Apple mobile SDK TOS affects more than just Adobe, take a look at the Open Source PhoneGap where you develop native mobile applications by programming using (the most popular language???) HTML + JavaScript. Thanks to the control freaks at Apple Inc, now this would not be possible. This is the same as saying that when you go on holiday to another country, you cannot use a translator to communicate and that you better go learn whatever language they speak in that country or STAY OUT!!!

First they didn't want Flash and Java to run on the iPhone. To be fair to them, those virtual apps kills the phone performance (so they say.). Therefore if you wanted to run any other program on their platform, you needed to translate it into a native app. EVEN THAT'S NOT LEGALLY POSSIBLE ANYMORE!!!! This is a big **** YOU to all the other programming languages. Can you imagine if Oracle said that Groovy, JRuby or Jython were not allowed to run on the JVM anymore? Or Microsoft saying Java app are not allowed to run on any MS platform through an intermediary (JVM)? Well, this is exactly what Apple Inc. is doing?

This is the best part; THERE IS NOTHING YOU OR I CAN DO ABOUT IT!!! Right now, the iPhone is the market leader for new generation of smartphones ( there are not the market leader in smartphone, that crown goes to Nokia) supported by its ecosystem of developer providing more than 150k apps in the App Store.

Look there is no way I am going to learn Objective-C unless I am getting paid for it. All we can do that is hope for Android, RIM and Windows Phone 7 to gain a large enough market share and we would see history repeat itself again. I am definitely not saying that you should boycott their products but if you are looking to build a company and make profit developing software for mobile devices, maybe you should think twice about venturing on the iPhone (off course, unless you know Objective-C).

Feel free to let me know your thoughts and I am sure that the Apple fanatics would not hold their thoughts on this one.


Posted by Unknown at 00:20
  • Blogger Comments
  • Facebook Comments

5 comments :

  1. Anonymous12 April 2010 at 07:27

    The iPhone is not the market leader for new generation of smartphones. RIM is the leader. There are more Blackberries sold than iPhones. See here:

    http://blogs.forbes.com/greatspeculations/2010/03/05/iphone-could-overtake-blackberry-market-share-in-2011/
    http://brainstormtech.blogs.fortune.cnn.com/2010/02/23/apple-android-rim-gain-market-share/

    I for one hope that Android overtakes the iPhone this year. I actually believe that it will.

    ReplyDelete
  2. Anonymous12 April 2010 at 09:16

    "Being developer I have invested to build knowledge and skills. I cannot learn every programming language and would welcome tools that help me to cross-compile my code."

    Apple want you to invest on their platform and they deserve it. That is because of all the hard work they did to make it as amazing as it is. Besides they have been burned like this in the past, and they ain't going let another win32/java happen again.

    ReplyDelete
  3. rogerv13 April 2010 at 08:08

    With Android phones and tablets, we'll be soon getting devices that permit access to 100% of the Internet.

    And with Google and Adobe now cooperating closely to pre-integrate the Flash Player into Google Chrome browser to provide seemless experience, we'll eventually be seeing Android and Chrome OS devices that have Flash Player bolted in, in a tightly integrated manner. Flex will become a first class SDK for programming RIA applications for such devices.

    The "full web" is essentially going to become defined by what the Google Chrome browser enables access to. Android and Chrome OS devices will reflect same. Apple will the the obstinate company that refuses to let its customers have full access to the web.

    ReplyDelete
  4. Werner Keil14 April 2010 at 09:50

    And if Palm really sells itself to Wireless modem leader Huawai, even they together might play a role. Huawai just released an Android device for Red Bull Mobile, a branded mobile carrier they got in some CE countries. The whole lifestyle and event culture Red Bull got is certainly a killer app for Apple and iPhone.
    Just look at how they outsmarted both Coke and Pepsi in the last decade.
    Which is what smart mostly Android based phone vendors are likely to do to iPhone or Blackberry, and probably Symbian/Nokia, too.

    ReplyDelete
  5. Anonymous19 April 2010 at 12:08

    Good Article - Ditto: http://blog.barbariancoders.com/2010/04/apple-now-with-two-scoops-of-dumbass.html

    ReplyDelete

Item Reviewed: Apple vs Geeks - is this the end of a love affair? Description: Rating: 5 Reviewed By: Unknown
Subscribe to: Post Comments ( Atom )