Rails项目API多客户端适配：如何从请求识别客户端返回对应错误状态码

Absolutely! You can definitely distinguish between your Unity parent app and iOS/Android child apps, then tailor your error response status codes to fit each platform’s specific requirements. Here are the most practical, reliable ways to pull this off:

1. Custom Request Headers (Most Reliable) #

This is the gold standard because it’s explicit and hard to accidentally break. Work with your Unity and mobile dev teams to have each app send a unique custom header with every request. For example:

• Unity app sends X-App-Client: Unity-Parent
• iOS/Android apps send X-App-Client: Mobile-Child (or separate values like iOS-Child/Android-Child if you need more granularity)

In your Rails app, you can grab this header anywhere in your controllers with:

request.headers['X-App-Client']

2. User-Agent String (Quick & Dirty) #

Most apps include a unique User-Agent (UA) string in their requests. Unity’s requests typically include UnityWebRequest in the UA, while iOS native requests might have CFNetwork and Android ones OkHttp or Android.

You can check for these patterns in Rails:

if request.user_agent&.include?('UnityWebRequest')
  # Handle Unity app
elsif request.user_agent&.include?('CFNetwork') || request.user_agent&.include?('OkHttp')
  # Handle mobile apps
end

Note: UA strings can change with app/OS updates, so this is less reliable than custom headers—but it works if you can’t coordinate with client teams to add custom headers.

3. API Keys/Client IDs (Secure & Multi-Purpose) #

If you’re already doing API authentication, assign unique API keys or client IDs to each app. Have the apps send this key in the Authorization header (e.g., Bearer YOUR_UNITY_KEY) or a dedicated X-API-Key header.

This not only lets you identify the caller but also adds a layer of security to your API. In Rails, you can validate the key and map it to a client type.

Once You’ve Identified the Client: Adjust Status Codes #

Once you know which app is calling, you can modify your error responses to fit their requirements. For example, add a helper method to identify the client, then use it in your error handling:

# In app/controllers/application_controller.rb
rescue_from ActiveRecord::RecordNotFound, with: :handle_not_found_error

private

def handle_not_found_error(exception)
  client_type = identify_client
  # Unity wants 2xx on errors; mobile wants 4xx
  status_code = client_type == :unity ? :ok : :not_found
  render json: { error: exception.message }, status: status_code
end

def identify_client
  case request.headers['X-App-Client']
  when 'Unity-Parent' then :unity
  when 'Mobile-Child', 'iOS-Child', 'Android-Child' then :mobile
  else :unknown # Fallback for unrecognized clients
  end
end

Pro Tips: #

• Coordinate with client teams: Make sure everyone agrees on header names/values or API keys upfront to avoid miscommunication.
• Test edge cases: Decide on a fallback status code for unrecognized clients (e.g., default to mobile’s 4xx, or return a 400 error).
• Use HTTPS: Always encrypt requests if you’re sending API keys or custom headers to prevent interception.

内容的提问来源于stack exchange，提问作者Muhammad Faisal Iqbal