It is unclear what you're trying to protect against, but in any case you're doing something wrong.
Are you trying to prevent an attacker from MitM intercepting legitimate users' traffic? Just use TLS (HTTPS). Seriously, it's the correct answer for this scenario. As long as you use modern ciphers and libraries (on both ends), you'll be secure against almost any conceivable (much less likely) attacker. If you want to be extra-careful, pin the certificate or public key info of your server (or your CA, at some level up the chain) so that even a compromised or malicious CA won't let somebody breach the communication channel.
Are you trying to use this as some sort of authentication mechanism? Using crypto to establish that both ends of the communication know a shared key, and therefore establishing the identity of the client, is a viable idea for a RESTful API (AWS, for example, does this with their SigV4 scheme). However, to do that, you need to use an authenticated form of crypto. Cipher Block Chaining (CBC) provides no authentication at all; an attacker who knows part of the plaintext for a message protected only by AES (or any other block cipher) in CBC mode can manipulate the ciphertext to produce a reliable change in the plaintext, and neither the victim nor the server will know. You may note that SigV4 doesn't actually do any encryption at all (only HMACs, a form of symmetric-key cryptographic signing); it isn't providing any confidentiality (HTTPS does that), only authenticity (ensuring that the message comes from the real source, and that it hasn't been tampered with in flight). You could fix this using an authenticated encryption mode of operation (like GCM), or by using asymmetric signatures (but then you may as well just use mutual TLS!), or by adopting a scheme like SigV4 (or just adopting it directly...), but your current scheme would not work.
Are you trying to prevent people from figuring out how to write third-party clients for your API? You can not prevent that. Don't bother trying. Whether by analyzing network traffic, reverse-engineering your binaries, or some other avenue, you can't prevent people from finding a key that you have to give your users. The best (in terms of technical knowledge and engineering resources applied) attempts at this are the commercial DRM systems that "protect" things like movies and commercial software, and those are still broken (sometimes with hilarious ease). It is fundamentally impossible to prevent them from being broken, in fact; the best you can hope for is to hide the key, and obscurity is not security.