Security is no secret. For web services you can do it in two basic ways:

1) Use Authorization: Basic base64(username:password) from the client. Because this sends the password with each request, you obviously should only do this over HTTPS.

2) Set a cookie on the server if the client provides the right name/password to some "login" service. When this cookie is present in future requests, assume the user is authenticated (for example, that cookie my also be a key into a session database that authenticates the user, or be a signature of the user ID.) The cookie should probably have some timeout mechanism in addition to the basic browser timeout values, because someone who sniffs the cookie can re-use it without enforcing the browser time-out. Using cookies without HTTPS is somewhat sensitive (see the Firesheep attack) so I recommend HTTPS there, too.

There are other options, like issuing an explicit token, and making it explicitly part of the URL or a custom header, rather than using cookies -- same security profile; harder for developers who already know HTTP to understand.

Finally, if the source of identification or authentication is a third party, like OpenID, there are other mechanisms as well.

For errors I would stick to google's best practices (for some reason it does not automatically scroll to #error, so go to "Top-Level Reserved Property Names" -> "error" or "Reserved Property Names in the error object" for more details on each field).

Personally, for API version I would go with url versioning instead of headers. It is easier to setup on backend (if you want to support old API calls) and is more transparent for API users (devs). Here you can find more opinions about it.

For example, if you use JSON, you may want the response to always contain the following fields:

status: "success" or "failure"
error: integer (if failure)
message: human-readable message (if failure)
data: actual-payload-data

Are you sure about status field? Isn't HTTP code enough? Like 201 is success or 400 for failure? (I am talking about good practices here, both will work, I just can not find any reason for adding this)

Finally, if the source of identification or authentication is a third party, like OpenID, there are other mechanisms as well.

I guess I will use generateIdentityVerificationSignatureWithCompletionHandler provided by Apple GameKit to authenticate the player. I can't find any good PHP example so I guess I have to write that PHP code myself.

Are you sure about status field? Isn't HTTP code enough?

If the data is transferred outside of a HTTP-aware wrapper, then the HTTP status will be lost.
This can happen in a few ways:

1) Inside the application, it's common to pass along a dict<string, object> or similar representing the decoded body
2) If using on-disk caching separate from HTTP caching (which may be necessary when using out-of-band invalidation channels) you're reading a file, not a HTTP server, and would have to somehow synthesize a HTTP response if your unit-of-information is at the HTTP level
3) If you switch to other transports, such as message queues or push notifications, there are no HTTP status codes (see for example Facebook Mobile's use of MQTT)