Fix bad resource name with Grape::API when used in Grape 1.2.0

[delner]

Grape released version 1.2.0 on 11/26/18 which broke our CI builds. In this new version, Grape deprecated the use of Grape::API directly.

Applications that are still using Grape::API after 1.2.0 will not be able to see the class name of the API in their trace resource names. This is because these well-known types are coerced into anonymous classes as noted in this issue. Users who experience this, as a workaround, should upgrade their base class from Grape::API to Grape::API::Instance as described here, e.g.

# Old
class MyApi < Grape::API; end

# New
class MyApi < Grape::API::Instance; end

To fix our CI build, we applied this change. To prevent misbehavior of tracing for users who neglect to undertake this upgrade, we hide the class name and tag, so as to avoid meaningless resource names like #<Class:0xXXXXXX>#success, in favor of #success.

UPDATE

Although the Instance object that's provided is an anonymous class, it turns out it is possible to resolve the name of the original class using the base method. I've updated the PR accordingly which means we now get the nice class name in resource for Grape 1.2.0 implementations that still use Grape::API, giving us backwards compatibility.

[dblock]

Given that this is now potentially mounted multiple times, is this change sufficiently differentiating between the two different mounted endpoints? I think the correct fix would be getting the API name + some instance ID (because there may be multiple mounted instances).

I commented ruby-grape/grape#1825 (comment) on whether this is needed in Grape proper.

[delner]

@dblock Yeah, maybe an instance ID would be useful. I'm not yet very familiar with the concept of mounted instances in Grape: how do different instances of the same API differ? Is it minor configuration or are there more substantial differences between instances of the same API?

[dblock]

@dblock Yeah, maybe an instance ID would be useful. I'm not yet very familiar with the concept of mounted instances in Grape: how do different instances of the same API differ? Is it minor configuration or are there more substantial differences between instances of the same API?

Technically, before we mounted a static module, now we mount instances of an API.

Logically you can define /foo in an API, but mount it as /v1/foo and /v2/foo, so the full path is very different. In previous versions of Grape this was not possible with the same code and you had to duplicate everything.

Note that there's a case where the path is the same, but the API switches by version. So /foo with an Accept header for v1 will give you an instance of the API mounted for V1, while /foo with an Accept header for v2 will give you an instance of the API mounted for V2. They may differ quite significantly obviously.

[delner]

@dblock I see, yeah, that could be very significant. We'd probably want to factor in that full path (in your example) to differentiate between the different instances because those represent fundamentally different kinds of operations (e.g. calling between versions 1 and 2.)