The "protect" which 4 is referring to is fundamentally like any other DRM: you're trying to give someone access to the content, but also deny it at the same time. In the case of an API, you've given someone an app which knows how to use it, which they can execute on their own computer and control the inputs of, and inspect the output.

If you don't feel like RE'ing the API, you can always just supply the inputs to the app yourself from somewhere else. ("All problems in computer science can be solved by another level of indirection", as the saying goes.)

Actually it is opposite, mobile platform is more secure.

But...

Security depends on ‘sense of security’, when people think platform is more secure, they tend to ignore/skip a lot of parts on security. Developer tend to skip edge cases (such as pizza API in this thread). When they are developing on secure platforms, they tend to skip more.

For example if you are developing for not jailbroken platform, you trust platform DRM (mostly consoles), and skip a lot of parts, you put the certificate pinning, and call it a day. When platform is broken, you are totally exposed.

But when you are developing for web, you are exposed from the beginning, you dont have that sense of security anymore, so you try to fix all edge cases.

Sure. The only way to sign requests is through something both parties can verify. The client you're using must have access to the shared secret key used in (e.g.) the HMAC process. While you can obfuscate the secret key to extents that would make a reverse engineer's life miserable (for a case study in that, see the Facebook app), you fundamentally cannot prevent the request signing process from being reversed with enough effort.

It's a very simple principle: the relevant data must necessarily be exposed, even if only in memory, at some point. Like any other DRM, it's imperfect.