Best way of structuring a library?

Question

I am busy building an app using the API and I am about to start to work with the API.

I have looked at the one other PHP library, and it is one object with method calls which return back a ResponseCore object. (Not sure on the whole response core thing tbh, why not an array?)

I'm not overly sure that sits right with me, however looking at other library's the "one object with method calls" seems to be the way people are going. Or am I missing good example of a library?

Would a library that had a classes like these be of any interest? Or something like this..

StackApp
StackAppAnswer
StackAppBadge
StackAppComment
StackAppQuestion
StackAppTag
StackAppUser

Or a one class "StackApp" that returns back some arrays be enough?

I'm really looking for a good way of structuring a library, I don't need a full representation of the api for my app but if I am going to programme up one part of the API I would like to do it neatly and open source it so other people can help complete it.

Answer 1

StackOverflow.Net uses the technique you described of having the API calls return the object or list of objects you are interested in. For example, GetQuestions() returns a list of Question objects.

So if you like to read C# check it out.

Answer 2

You could check out StackKit, which has objects all over the place and is currently being refactored to have even more. At a quick glance, we have:

• SKSite - an object representing any site that exposes the StackExchange API.
• SKObject - abstract superclass of most SK* objects with some common functionality
• SKUser - an object representing a user on a site
• SKUserActivity - a piece of information from a user's timeline
• SKPost - an abstract class representing some post, with info about it (author, creation time, body, etc)
• SKQAPost - an abstract class representing a question or an answer, a subclass of SKPost. Holds more information specific to QA posts
• SKQuestion - an object representing a question. Subclass of SKQAPost.
• SKAnswer - an object representing an answer. Subclass of SKQAPost.
• SKComment - an object representing a comment. Subclass of SKPost.
• SKBadge - an object representing a badge (awarded or not)
• SKTag - an object representing a tag
• SKFetchRequest - an object representing a request for specific information. The request contains several properties, such as an "entity" (an indication of what kind of information you're requesting, like users, questions, or whatever), a predicate (limiting what objects get returned), or a sort descriptor (indicating how you want the objects to be sorted). Fetch requests can be executed (via the SKSite) either synchronously or asynchronously.

I'm currently refactoring the fetchRequest validation into a hierarchy of "SKEndpoint" objects to make adaptation to API changes easier...

Answer 3

If you want simple, look at MSOEngine. It's also written in Objective-C. It's slightly harder to use then stackkit, but the code is simpler and easier to understand, and doesn't use any memory mangement! (it's coming I swear!!!) Also, on an unrelated note @Dave DeLong, why did you model it off of core data?