Assuming that your chosen language either has good support for connecting to HTTP web services, or that a suitable library has been identified, then making a data transfer from your required service is not going to be a problem. However, what happens if the connection fails? While native GUI applications typically sit on a desktop or laptop computer where permanent network connections are common, it is not wise to rely on this. With increased remote working, coffee shop meetings, and higher levels of mobility (enabled by Wi-Fi and cellular networks), any modern application needs to handle unexpected network conditions.

When developing a web-based application, it may not be necessary to be as diligent as the user is probably already online. It's also possible that a failure of the internet connection could represent a fatal situation for the software, so in some situations an error displayed to the user asking them to try again later may be acceptable. However, user expectations of native graphical applications are far higher than this. Smart phones and the software they come with are expected to gracefully handle such failure conditions caused by frequent changes in network condition or availability. So, what can we do to match this higher expectation in these situations? This probably takes some planning; the error message of Try again later must be a last resort.

How much of your application actually requires an internet connection all the time (or at a specific point in the workflow)? Are there elements that can be accessed occasionally and stored locally (cached)? And is it OK for outgoing communications to happen at a later time, rather than immediately on user action? It's helpful to be creative when thinking about a network connection and when it's really needed. Not too long ago, a chat client (such as IRC, ICQ, MSN, and others) would need to be online all the time, and if the connection stopped responding, you'd have to wait until it reconnected. More recently, expectations have shifted and new chat services (such as Slack and Skype) will allow you to type into chats or channels even when offline, and messages will be delivered as soon as they can.

One additional challenge in a web-based connected world is authentication. Old password- and application secret-based authentication worked easily within most programming languages, but they had security issues. The most recent standard to be adopted is OAuth2, which aims to ensure that the user knows what they are allowing when applications connect to a secured service. The workflow is designed to work well in a web browser, but from within a native application, will it be a reasonable user experience to switch to a web browser when asking for permission? Will you improve the flow slightly by embedding a web view within your application? Unfortunately, it's been noted that this is also open to potential security attacks, and there is now a document focusing on the best practices for OAuth2 integration into native applications (IETF RFC 8252). Adapting applications to implement these recommendations will become a requirement over time.