What you have here is basically a RESTful webservice API. This is in fact a quite popular solution. The main advantage is that it is not technology-specific. You can consume it with client applications implemented in a very wide variety of technologies. This is especially important in a case like yours where you are working with an obsolete technology like Flash. Down the line you will be forced to abandon it due to lack of browser support. But as long as you are using web services to communicate with your backend, you will very likely be able to keep using them with your new game client.
In the context of game design, there are however two drawbacks:
- It usually sends text data. You might be able to save a lot of bandwidth when you use some binary encoding.
health=100&mana=50&strength=10uses 30 bytes of text to communicate 3 integers. You could do that with 12 bytes if you just send 3 32-bit binary numbers. Even less if 16 bit or 8 bit are sufficient in your case (8 bit would be enough in this particular example, but I don't want to assume you won't ever have more than 256 in any of these attributes).
Note that webservices can return binary data. It's just a very uncommon thing to do. But don't let that stop you.
- HTTP uses the TCP protocol. This is fine for slower-paced games. But it isn't suitable for action-oriented games where every millisecond of latency matters. When your game is one of these, it would be better to use UDP if possible.
Flash supports UDP, but only on the Adobe Air profile, not for the web player. But the usually recommended replacement for Flash web applications (HTML5 + Javascript) does not support UDP either. So when you want to use UDP, you will have to transit from a web application to a native game client.