2

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.

3 Answers 3

2

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.

1
  • From the small example it seems that this is in the single parent class setup? StackOverflowClient controls everything and you call methods on that?
    – johnwards
    Jun 3, 2010 at 6:28
0

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...

3
  • Oh god. I really need to get my head around Objective-C and those square brackets. I am sure it is what I am looking for but it will take me a little while to get my head around objective-c and then how you structure stuff.
    – johnwards
    Jun 2, 2010 at 19:55
  • @johnwards as we Cocoa users say, "Embrace the Brackets!" :) I'll edit the post with a bit more contextual information. Jun 2, 2010 at 20:08
  • Consume you, the brackets will. Jun 4, 2010 at 2:30
0

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?

2
  • I modeled it off of CoreData because SO is essentially a glorified data store, and a lot of Cocoa devs are familiar with how CoreData works. It seemed to me that by mimicking it, it would help lower the barrier to adoption. The significant architectural difference is that in StackKit, you can execute requests asynchronously, which you can't do in CoreData. Jun 2, 2010 at 22:03
  • ah. Now it makes sense! When I first saw you were modeling it off of Core Data I thought you were a little nuts. But now it makes perfect sense to me! I originally modeled mine off of MGTwitterEngine, but I slowly moved away from it because I wanted to make it easier to include new API features
    – Matt S.
    Jun 2, 2010 at 22:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .