[Tutorial]How to make API for your plugin?

Discussion in 'Resources' started by KaSkA3eR, Dec 28, 2013.

Thread Status:
Not open for further replies.
  1. Offline



    I'm 13 years old programmer and i wanna show you how to make API for your plugin.
    OK Let's start.
    Make a class named for example api.java.
    In her add your functions which you wanna have in API
    For example:
    public void setPlayerCoins(String pname, int quantity)
                Statement statement = Coins.c.createStatement();
                statement.executeUpdate("UPDATE....LIMIT 1;");
            catch (SQLException e)
    If you want access variables from Main class you must import class for example:
    import org.kaska3er.coin.Coins; (Coins it's my Main class)
    Your variables must be static;
    Then you add <nameofmainclass>.<nameofvariablewhichyouuse> if you want access it.
    In my case I have a variable in my main class:
    static Connection c = null;
    And if i want acces it from api class i must make a this code:
    Statement statement = Coins.c.createStatement();
    OK if you make api class with your functions go to main class.
    Add this code before onEnable:
    private static YourMainClassName plugin;
    In onEnable write:
    plugin = this;
    Under onEnable write this code:
    public static YourMainClassName getPlugin()
            return plugin;
        public YourApiClassName getApi()
            YourApiClassName app = new YourApiClassName();
            return app;
    And it's finish. If you want use your functions in other plugin you must add jar of your plugin to build path and ad this code into onCommand/onEnable or anything public:
    if(this.getServer().getPluginManager().isPluginEnabled("PluginNameFromPluginYml")) {
                  ApiPluginMainClassName anything = (ApiPluginMainClassName) this.getServer().getPluginManager().getPlugin("PluginNameFromPluginYml");
    Thank you for your attention
    ArthurMaker likes this.
  2. Offline


    This isn't a very good resource.. Many people who are new to these sorts of things would think that they have to use SQL Statements.. Also, it hasn't been written very well. Try putting more time into things like this; you will receive a better outcome.
    macguy8 likes this.
  3. Offline


    Why do you start off with saying that you're 13?
  4. Offline


    Because he wants us to know all of his personal information so we can find out where he lives. -.-
    AlexMl likes this.
  5. Offline


    Also doesn't have a lot of ways an api can be done.
  6. Offline


    One thing... You never want to expose your plugin, you want to expose your API class. Once you expose your plugin then others can overwrite specific data in your plugin that could potentially break your plugin.

    And your way of making an API is plugin specific as people have to use "YourMainClassName.getPlugin().getAPI();" Its better to have a class that people make new "MyAPI api = new MyAPI();" Then they don't have to travel through your plugin to get to it... (An example would be this)
  7. However, sometimes they need to. It's the same when we need to access craftbukkit or nms features, because the api just won't let us do that. Since an api most of the times gives us only interfaces (I mean come on it's already named like that: application programming interface) we *should* not bother about the implementation of it, but we should be able to use the implementation to do more things which are not provided within the api sometimes. When they could break things, then you made a mistake, because you allowed them to break it. What if the same thing happens, which occurred because someone used your internal parts, suddenly without someone interfering? That could possibly happen, even if it might be unlikely. It's your duty to not let this happen under any circumstance.

    Well, I can't really say yes or no to this one. It's certainly not a bad way to do it, but the proposed one isn't either. In your case for example, you're assuming that there can be multiple instances of the api, but what if there can only be one instance of it because it needs all the data from all the plugins it's used by? It wouldn't work in your case but would be completely fine in the OP's way. Like I said, they're both not bad ideas and one isn't better than the other, it all depends on how you want to do things or what your preferences are. I personally don't like that others need to create an "api object" or do you create a bukkit api object? I haven't seen that. I would at least make a static method which creates my api internally to have a bit more protection.

    Back to the topic and to KaSkA3eR :
    I would've loved to be able to program java at the age of 13 but it looks like I wasn't into programming at that point and it seems that you've learned a lot already. But when you learn more, you'll see that there's far more complexity behind an api. Sometime later you should come to the point where you'll notice that an api is just a principle and does not apply to a specific language and thus you can't really tell a person how to make an api by saying do this and do that in the code, it just won't turn out good. Instead, you should focus on what the principle is trying to convey and express.
    An api should give the user a unified way to use functionality which you are providing. The user should not bother how you do things and only focus on what you need and what he'll get. Everything else is your part, nothing more and nothing less. An api can't be written in a general sense. An api has to be written with a program behind it, like an existing plugin or at least a plugin which you'll write around it.

    In the beginning it's really hard to look at things in an abstract way and it's way easier to look at a specific implementation in a specific language. But that's not good. At least try to see the idea or principle behind it. A good programmer should be able to implement a principle everywhere, not just in one specific language. That's my way of thinking about it.
    KaSkA3eR likes this.
Thread Status:
Not open for further replies.

Share This Page