Differentiation between API key's [Private/Shared]

[wizard-chan]

This suggestion applies to backend API development stuff, normal users probably won't see any difference with how the site functions.

I'll explain the issue:
I've been working on an API wrapper for the MC-Market REST interface recently, and noticed that I have to manually specify and check private and shared key types, on the user-end. This is a slight inconvenience to anyone who develops with the API, as they have to check which keys apply to which methods (which involves reading documentation, or doing tests on the requests).

As it stands, the keys currently generated are random encoded bytes, identical in generation for each key type. The new system I'm suggesting is a change in how each of the keys are generated, this can be implemented a few ways.

Implementation Method #1:
Include a unique character or series of characters before each key. I.e. Include "Shared-[key]" and "Private-[key]" before each key type. This way the security benefits of shared/private keys remain the same as they are at current, however they're detectable as the specific key type.

Implementation Method #2:
Differentiate between the length of each key type. I.e. Make private keys have one more base64 encoded byte.

I.e.
Shared: XXXXXXXX-XXXXXXX-XXXXXXXX
Private: XXXXXXXX-XXXXXXX-XXXXXXXX-XXXXXXXX

As a developer, differentiation between public and private keys is important to the overall usability of the API as a whole. Specifying it manually on the developers end is inefficient and overly complex. As well as wasting their precious time reading documentation.

I'm trying to make an API which is as easy to use as possible.

 

[Harry]

I've been working on an API wrapper for the MC-Market REST interface recently, and noticed that I have to manually specify and check private and shared key types, on the user-end.

I guess I'm slightly confused about this specific issue you're trying to solve here.

As you've already alluded to, you'll receive an API error if you attempt to call an endpoint that your token doesn't support. So unless you're writing in a compiled language, all manually checking these would do is replace a runtime error with another runtime error. The only benefit would be the single request never being sent, but with the headache of needing to maintain those checks for all future API updates & additional token types.

 

[wizard-chan]

I guess I'm slightly confused about this specific issue you're trying to solve here.

As you've already alluded to, you'll receive an API error if you attempt to call an endpoint that your token doesn't support. So unless you're writing in a compiled language, all manually checking these would do is replace a runtime error with another runtime error. The only benefit would be the single request never being sent, but with the headache of needing to maintain those checks for all future API updates & additional token types.

The point Harry is to not have to send the incorrect request to the API in the first place. It's no too much of a headache for me personally, and the change wouldn't actually change the functionality of any current API wrappers.

 

[Harry]

The point Harry is to not have to send the incorrect request to the API in the first place. It's no too much of a headache for me personally, and the change wouldn't actually change the functionality of any current API wrappers.

So how does the solution of making the token value identifiable actually solve this issue?

Your wrapper would then need to parse that token value & determine the token type itself - why is that any better than the developer providing the token type & value together?