REST API and OAuth.

Status
M

MarkFreak

Feedback score
11
Posts
558
Reactions
280
Resources
0
WARNING: Croc made a thread for one, but it's been closed, with no response from Mick and it's just closed without having it moved in the denied section.

DISCLAIMER: If you're not a developer, you may not find this needed, but think about it that's not a reason to disagree with the suggestion.

ADDITIONAL: This post does not mention the OAuth which I have in the title, but if Mike you're reading this, before denying the API, atleast give us your opinion on OAuth.


Fundamentals:
  • Authorization: To obtain an API key, perhaps Supreme or Premium and then rate-limiting as below would make it non-abusable (not technically but ideally there would be someone looking at logs).
  • Rate limiting: We know how this community is (DDOS'ing, toxicity etc...), so rate limiting is crucial. In a way that authorization would be like above, rate limiting shouldn't limit developers who are trying to make a proper application, so I suggest a compromise of what Mick can allow, I'd say anywhere from 10 requests/second to 2 requests/second.
Structure (for non-developers to understand the importance, and not get this wrong):

The REST API would only accept GET methods which would allow:

  • Users to get information about others public information, get info from threads and other...

and would not allow:

  • to CREATE anything thru the API. This includes but is not limited to sending messages to DM's, creating threads and posts...

Examples and endpoints:

GET to /user/{user-id} returns:

Code: 
{"username": "Natsu", "reputation": ["positive": 1, "negative": 0, "neutral": 0], "status": "Writing amazing suggestion."}


that's just one example but enpoints for getting posts of threads and such would be very nice, but honestly I'd push parts of the API when done and the user endpoint would be the one really considerable...
 
Type
Suggestion
Status
Denied
Upvote 7 Downvote
PebbleHost
High performance, consistent uptime and fast support. Minecraft hosting that just works.
1337

1337

ash is our purest form
Supreme
Feedback score
159
Posts
1,541
Reactions
1,523
Resources
0
MarkFreak said:
WARNING: Croc made a thread for one, but it's been closed, with no response from Mick and it's just closed without having it moved in the denied section.

DISCLAIMER: If you're not a developer, you may not find this needed, but think about it that's not a reason to disagree with the suggestion.

ADDITIONAL: This post does not mention the OAuth which I have in the title, but if Mike you're reading this, before denying the API, atleast give us your opinion on OAuth.


Fundamentals:
  • Authorization: To obtain an API key, perhaps Supreme or Premium and then rate-limiting as below would make it non-abusable (not technically but ideally there would be someone looking at logs).
  • Rate limiting: We know how this community is (DDOS'ing, toxicity etc...), so rate limiting is crucial. In a way that authorization would be like above, rate limiting shouldn't limit developers who are trying to make a proper application, so I suggest a compromise of what Mick can allow, I'd say anywhere from 10 requests/second to 2 requests/second.
Structure (for non-developers to understand the importance, and not get this wrong):

The REST API would only accept GET methods which would allow:

  • Users to get information about others public information, get info from threads and other...

and would not allow:

  • to CREATE anything thru the API. This includes but is not limited to sending messages to DM's, creating threads and posts...

Examples and endpoints:

GET to /user/{user-id} returns:

Code: 
{"username": "Natsu", "reputation": ["positive": 1, "negative": 0, "neutral": 0], "status": "Writing amazing suggestion."}


that's just one example but enpoints for getting posts of threads and such would be very nice, but honestly I'd push parts of the API when done and the user endpoint would be the one really considerable...
Click to expand...
Croc said:
Well formed suggestion MarkFreak, I agree completely! Now just all that needs to happen is for Mick to approve and implement, but as we all know, he can be quite stubborn.
Click to expand...
An addon has already been made for this - https://xenforo.com/community/resources/xenapi-xenforo-php-rest-api.902/

There is very little reason not to add this, and it would require basically 0 custom development.
 
M

MarkFreak

Feedback score
11
Posts
558
Reactions
280
Resources
0
Croc said:
Well formed suggestion MarkFreak, I agree completely! Now just all that needs to happen is for Mick to approve and implement, but as we all know, he can be quite stubborn.
Click to expand...

That's the biggest problem, Mike. Joking aside Kappa I'd honestly be fine with an user endpoint as a starter then progress more.

Fox said:
An addon has already been made for this - https://xenforo.com/community/resources/xenapi-xenforo-php-rest-api.902/

There is very little reason not to add this, and it would require basically 0 custom development.
Click to expand...

Unmaintained, from 2012 aka out-dated, too bulky as only GET methods for MC-MARKET would be possible to maintain. I appreciate your help, but I'm afraid that this is not a option.

There's not much development in the API, I don't know how much work is much for whoever develops this, but if the whole database is well structured it's low amounts and it's quite worth it.
 
Last edited:
Mick

Mick

BuiltByBit Owner
Management
Feedback score
28
Posts
6,411
Reactions
7,662
Resources
0
MC-Market does not allow for people to interact with the site through automated means, so I don't understand why we would introduce an API to make that easy for users to do.

There is no need for an API on MCM to make proper applications for the site.

Denied, thanks for the suggestion.
 
Status
Top