RE: Steem API-Wrapper for Java - V0.0.2 Released #Update2
What a disorganized and sprawling API !!! It needs to be abstracted into a simpler, easier to use and understand version so it isn't such an obstacle to adoption.
I haven't looked at Xeroc's "Piston" library for python yet, but it is on my list of code to start getting into. I hope it does more than mirror this graphene behemoth and actually refines and abstracts the API.
In my opinion every programmer that takes on the challenge of creating an interface to the graphene API for a different language should also consider doing so in a way that makes using graphene easier for others to learn.
I recognize that is likely an iterative task that takes additional time which may not be necessary to achieve a project's goals or in its schedule to complete, but it's worth thinking about as you create the interface.
Another impediment is simply understanding the plethora of graphene calls in order to abstract them into a higher level of consistency and usefulness. To many the tradeoff of expediency to understand what is necessary to meet a project's requirements and focus only on those API elements may be the difference between reaching the market ahead of competitors or being too late.
First, thank you for the feedback. I think you are basically right in what you are saying, but you have to take care about what you are looking at here. The most projects (steemJs, steem-rpc, steem-cli, and even this project) are simple api wrappers for a specific programming language and nothing more.
No one stops us from creating cool and abstracted services, but all of them will need one of the api wrappers above. Maybe in the future, after this wrapper has been finished, someone will create one of those utility projects that allows an easier access to the steem data.
I'm not sure what your efforts are directed at in providing a wrapper to the API if you haven't got a use for it other than to provide an interface for a specific target language, i.e. you don't have an application in mind.
If that's the case you have the perfect opportunity to do more than just provide a wrapper. You can actually improve access to graphene by defining a new API in the target language which combines similar API calls and objects. Reducing the sheer number of API calls alone would help reduce the API learning curve and improve graphene adoption.
I also see many API calls that are specific to steem. This comment is more directed at cryptonomex (i.e. @dantheman) that you, unless you can easily see the distinctions. This would be another great opportunity for a naming convention to identify app-specific graphene API calls (i.e. BitShares, PeerPlays, Steem, Muse etc). Ideally application specific API calls shouldn't even exist but should be their own dedicated layer on top of the core graphene layer. Note that I said ideally; I recognize that isn't always possible for the sake of efficiency but designs that are designed that way from day 1 are better IMHO.
Another refinement might be to simply group the API calls into related blocks that correspond to the docs (like this basic description of the APIs. You did this in your listing above but it would be even better if the API calls had a prefix or naming convention to make it obvious which API each call was a member of.
Surely you can see similarities of some API methods and data that could be combined or a organized into a better structure. Why have a separate "get_discussions_XXX" API call for each type of XXX rather than a single class with overloaded arguments? Hide all that from the programmer new to the API. Of course each of those methods must exist in the class but I see no reason to bloat the API with such granularity, at least not for a capable object oriented language like Java.
There are some applications that I have in mind, but as I said before: Everything that I or someone else of the community wants to do, needs some kind of this api wrappers. There is no way of creating an application without this.
Again you are right, but in my opinion an abstracted, new api is a new project that can be build upon this wrapper and combine its methods. This allows the developer to decide if he want‘s a light weighted api wrapper or a more heavier utility-project which offers him some easy ways to do the things he wants to do. I hadn‘t the deepest look into the piston project, but after the first look it seems to be exactly this: An additional application basend on the steem api wrapper written in python.
True.
There are many good points here! Thank you for that :) - I‘ll keep it in mind.