This chapter is from the book
This chapter is from the book
This chapter is from the book
Client Layer
After you build your complex application server, you need to focus on making that simple WebAPI usable to your clients. Although developers may be fine with talking XML or JSON to your service, the average user probably won't be, so you need to build a client layer. The biggest concept to understand about this layer is that you cannot trust anything it sends. To do so means you're authenticating the client, and no matter what kind of protection you try to do, it's impossible to ensure that the information you get from any client is your client.
You must assume that everything you send to your client is viewable by the user. Don't assume the client will hide things that the user shouldn't see. Almost every web service-based vulnerability comes from just blindly trusting data coming from a client, which can often be formed specifically for the purpose of making your application do something you didn't intend. This is the entire basis behind the SQL injection issues many websites still suffer from. Because of these types of security concerns, you have to ensure that all authentication and authorization happens outside of this layer.
You can develop this layer in several different ways, the easiest of which is to expose the API and allow other third-party companies to build their own clients. This is the way that companies such as Twitter handled creating its clients. You can also make your own clients, but by having a well-documented and public-facing API, you expose yourself to having other people and companies developing their own clients. In general, you have to be ready for this event, so it's always a good idea to ensure that the client layer has only the access you want it to have. You can never tell for sure that the client you're talking to is one that you've developed.
Browser-Based Clients
With the release of the HTML5 specifications and local database storage, it's become increasingly easier to make rich HTML and JavaScript-based clients. Although not all browsers support HTML5, and even less support local databases, it's still possible to create a rich experience for the user with just a browser.
Although some browsers do support cross-site Ajax requests, it's generally not a good idea to rely on that. Instead, use something such as Apache or NginX to proxy a sub-URL that can be used by your JavaScript client. Don't be afraid to use Ajax requests for loading data. It's also a good idea to build up a good base set of functions or use an existing library to handle all your serializing and deserializing of your objects, and making Ajax requests and handling caching of objects. You don't want to hit your server more often than absolutely required because HTTP requests are relatively expensive. So it's a good idea to keep a local cache if your browser supports it, but don't forget to either keep the memento provided, or the time when it was retrieved so that you can send an If-Modified-Since header with each request.
If you use a JavaScript-based client layer, it's strongly recommended that you use something such as jQuery to handle all your cross-browser issues. Even if you hate using JavaScript, jQuery can make creating this client layer simple. This, however, can be tricky because it relies a lot on the browsers feature support, which can be entirely out of your own control. Additionally, this generally doesn't work well for mobile devices because those browsers have much less JavaScript support, and they typically don't have much memory at all.
If you don't want to use JavaScript, Flash is another option. Flash has several libraries for communicating over HTTP using XML, so you should use something that already exists there if you want to support this. If you don't like the representations that these libraries supply, you can also use the Accept header and a different version number to allow your system to support multiple different representations. Flash has the advantage of being easy to code in, in addition to providing a much more unified interface. It's also quite heavy and can be easy to forget that this is an untrusted layer. Most mobile devices don't support Flash, so if that's important to you, you need to stick to JavaScript and HTML.
Another option if you don't want to use either HTML/JavaScript or Flash is using a Java Applet. Although there's a lot of possibilities that you can do with these little applets, they're also heavy weight, and if you're trying to get it to work on mobile browsers, this just won't work. Additionally, few mobile devices support either Flash or Java Applets, so if you're going for the most support, you probably want to stick with HTML and JavaScript. Still, if you need more features than Flash or HTML can support, this might be a good option for you.
Native Applications
If you've ever used Twitter, chances are you know that not only is there a web interface, but there are also dozens of native client applications that work on a wide variety of platforms. In your system, you can make as many different client applications as you want to, so eventually you may want to branch out and make some native applications for your users. If you're building that wonderful new electronic filing cabinet to organize your entire world online, it might be a good idea to also provide some native apps, such as an iPhone application that also communicates to the same API as every other client to bring you the same content wherever you are in the world.
Even if you're not the one building native applications, it may still be a good idea to let other third parties have this option. If you make your API public and let third-party companies make money from creating client layers, you not only provide businesses with a reason to buy into your app, but you also don't need to do any of the development work yourself to increase your growth. Although this may not seem intuitive because people are making a profit off your system, every penny they earn is also bringing you business, and chances are they're marketing as well. Not only does this give your users more options for clients, but it also gives your system more exposure and potential clients.