API

[BrianGrug]

I think that there should be an API for resources because it would help resource makers know when they make a sale/download, and maybe even make a Discord bot that connects with Mc-Market. Here are some of my ideas for an API:

1. Get ratings
2. Push updates
3. Get updates (For example a bot creator can make it so a update is shown in #updates in Discord)
4. Maybe even download ID's like Spigot has
5. Get a list of new resources

And if anyone has anymore ideas share them below

 

[Ally]

As developer I would love MCMarket to have an API like Maximvdw created for Spigot (https://github.com/Maximvdw/SpigotSite-API).
Unfortunately without MCMarket allowing this and adding this we aren't able to do anything.

Of course you can make an API for MCMarket...

... it'll just be painstakingly slow due to Cloudflare and you won't be able to share people or let anyone know you have one, given it's against the rules. For this suggestion to be implemented, rules have to change to allow for it and the users.

Either way, this has been suggested before and I'm pretty sure the other one is in Pending.

 

[Mick]

Justis, BucketOfSloths, got feedback on this?

 

[Ajdin]

Just today, Xenforo has announced an API for Xenforo 2.1.

https://xenforo.com/community/threads/rest-api.155632/

 

[Harry]

Of course you can make an API for MCMarket...

... it'll just be painstakingly slow due to Cloudflare and you won't be able to share people or let anyone know you have one, given it's against the rules. For this suggestion to be implemented, rules have to change to allow for it and the users.

Either way, this has been suggested before and I'm pretty sure the other one is in Pending.

I know this comment was posted a while ago, but CloudFlare just put out this article - https://support.cloudflare.com/hc/en-us/articles/200504045-Using-Cloudflare-with-your-API

The problem with introducing an API is that all IDs for members, threads and resources are incremental, instead of a randomly generated IDs (for example, a Base64 string). This means that someone with access to such an API could, in the right circumstance, incrementally fetch data on every single member, thread and resource in the matter of minutes.

Unless I'm missing something here?

 

[Harry]

No they are not increased.
It is their unique id. Regarding the threads, it is the same even if you delete.

Yes, it's their unique/identifying ID, but it's still incremented. That's why you can go to a thread like https://www.mc-market.org/threads/348725/ which is only an increment of 2 - you could easily set up a script to go through the whole range and fetch that thread's data from the API.

This is why websites such as Youtube use Base64 strings, so you can't just go through and increment the ID.

 

[Harry]

Anyway the API is meant to fetch user's mostly.

So you ain't gonna fetch a potential leaker of resource and retrieve what was he posted, would you ?

I have no clue what you're on about... but I'm just identifying some vulnerabilities if they implemented an API.

I'm just saying that I doubt they want people to be able to compile a single JSON file of all members, resources, and threads, which could be done if they implemented an API as is.

 

[Ajdin]

I know this comment was posted a while ago, but CloudFlare just put out this article - https://support.cloudflare.com/hc/en-us/articles/200504045-Using-Cloudflare-with-your-API

The problem with introducing an API is that all IDs for members, threads and resources are incremental, instead of a randomly generated IDs (for example, a Base64 string). This means that someone with access to such an API could, in the right circumstance, incrementally fetch data on every single member, thread and resource in the matter of minutes.

Unless I'm missing something here?

Why is that a bad thing? This can already be fetched without an API.

 

[Harry]

Why is that a bad thing? This can already be fetched without an API.

Do you mean just by looking at thread or? If so, how are you going to parse this data easily into JSON? The whole point of the API would be to make this process of fetching the data a lot easier, but then you could just go through every thread and put it into a single file.

I just think it needs to be implemented in the right way, so it's not abused.

 

[Justis]

I'm against push notifications, but a REST API allowing resource authors to retrieve purchase and download information including:
- Versions
- User ID/Name
- Time-stamps
- Count

(If we introduce NONCE injection into our resources, which I'm all for, we can also include the NONCE in the returnable information)

Could be very useful for resource authors wanting to personally fight against leakers and or provide any sort of additional automated service to their buyers.
I would like for each resource to come with a uniquely generated random key, only accessible to the resource author, so these stats stay private to the resource author unless they want to share it, and the API be accessible only when the correct key is provided. Resource authors should be able to reset their resource's key.

Additionally, a public API for retrieving resource update information including:
- Versions
- Time-stamps
- Ratings

Would be useful for people looking to automate the process of checking for resource updates for the resources they use, whether by the resource author for the resource users, or the users themselves.

I'd just recommend it be located on a separate server.

 

[Mick]

I'll move this to pending.

Thanks for the suggestion.

 

[Anvity]

Uuh, it would be really helpful for everyone, it would avoid leakers and more as Spigot does...

 

[Maximvdw]

To add my 50cents to this:

My use cases for an API are the following:
- Buyer verification (The ability to create a web application that fetches buyers/licenses of resources)
-- e.g. https://buyercheck.mvdw-software.com/
-- e.g. Discord bot to assign MCM accounts to a support channel
- Adding/removing buyers (The ability to create other payment gateways that add buyers to MCM, think of Stripe or other payment methods without relying on MCM to implement them)
- User verification methods (reading profile posts to validate another user)
-- e.g. discord bot that verifies that your discord is owned by your MCM account ("Post this on your profile to verify,...")
- Conversation creation/reading
-- e.g. Used it this summer on spigot to allow other people to read and respond to conversations/support tickets without giving access to my account
-- e.g. Automatically send a license or support information when someone buys a resource

 

[GrantisJ]

I think that there should be an API for resources because it would help resource makers know when they make a sale/download, and maybe even make a Discord bot that connects with Mc-Market. Here are some of my ideas for an API:

1. Get ratings
2. Push updates
3. Get updates (For example a bot creator can make it so a update is shown in #updates in Discord)
4. Maybe even download ID's like Spigot has
5. Get a list of new resources

And if anyone has anymore ideas share them below

I agree with that. It would really make things easier and better.