If you find any errors, typos or have general feedback, select the text and click CTRL+ALT+ENTER.


Appery.io comes with a very powerful and easy way to define and consume REST services in a mobile app. Inside the builder, you have access to what amounts to a very easy-to-use REST services console, where any service can be defined, tested, and have its response parameters automatically defined.

Being able to run and test the service from inside the builder is very important, as it demonstrates that the service works and the data is returned. The next steps are usual to make the service available on the page, define UI-service data binding, and then set the service to be invoked on some event. But when testing the app in a browser, the services sometimes don’t work, or no data is returned. This creates confusion, since the service that worked while testing inside the builder, doesn’t work when invoked from a browser page. This happens because of the cross-domain security built into browsers.

All browsers have this built-in. To invoke a service via JavaScript (AJAX) from a domain like “mydomain.com,” the page from which the service is invoked has to be hosted on that same domain, mydomain.com. When testing an app built in Appery.io, the page is running on Appery.io but the service being invoked is on a different domain, such as “search.twitter.com.” The browser won’t allow this. This is by design, to ensure that no malicious JavaScript code can be used to invoke the service.

So what can be done? Luckily, there are a number of options to make this work:

Host on the same domain

The most obvious option is to host the page and the service on the same domain. This solution is simple, but not very practical today because of the shift to a client-cloud architecture. Many services used in mobile apps today are cloud-based, and are hosted via different API providers and thus are on different domains. Hosting the page and the service on the same domain might work well if services were deployed completely within the same organization.

JSONP (JSON w/Padding)

JSONP is the unofficial way many providers solve the cross-domain problem. Instead of making a regular AJAX request, which is subject to cross-domain security, the request is made via loading a JavaScript file with a special callback function defined. Since loading a JavaScript file isn’t an AJAX call, it doesn’t fall under the cross-domain security problem. The callback function is then invoked to process the data returned (which is JSON). The URL looks like: http://someurl?callback=getthedata. Getthedata would be invoked to process the response. With JSONP, a service can be invoked from a page hosted on a different domain. For example, Twitter’s API supports JSONP and thus, can be invoked from Appery.io hosted pages. However, it’s up to the service to support JSONP, and not all services support this feature.

Cross-Origin Resource Sharing (CORS)

While JSONP could be considered a hack or a workaround, CORS is an attempt to create a standard way to solve the cross-domain issue. When a service request is made, the server will include a header parameter in the response, indicating that the domain from which the call was made is allowed to invoke this service. However, it’s up to the service providers whether to add this support. For example, the Parse mobile back-end service supports this feature, and makes using their services very easy.

Appery.io proxy

If none of the above options are available, the Appery.io mobile app builder provides a proxy service that works for testing. When using the proxy, the request is first sent to the proxy server and then, from the server, the request is made to the service. Because the request is sent from the server and not from the page, cross-domain security is not triggered.

Google Chrome w/security disabled

The last option is only useful in development or testing. You can start Google Chrome with security disabled, in which case the cross-domain issue is no longer a problem. To start Chrome with security disabled, start it with this command line: chrome –disable-web-security.

More help resources

More help resources are links to the blog, our YouTube channel and other web sites.