Are you dogfooding this API internally? Tacking an API onto an existing site makes maintenance harder and leads to diverging features. Using the same API as your users generally leads to a nice API.
This is the ultimate test of usability. You need to make this API the tool you use for ALL of your interactions with the underlying server architecture.
If you have a special set of tools whose utility outstrips that of your public-facing API, then you'll always have to replicate that work for the public sooner or later, and now you're supporting two APIs instead of one.
Honestly, that is one thing that has to be seriously considered. I don't care for a longer development time frame, most people can wait. We can be spoonfed, to a certain extent. I think it would be better, for devs and for users, to get some good APIs, stable and well implemented, than getting some half-assed API that breaks all the time and is hard to fix.
More work for you in the first place, but it will make our life and yours easier in the medium-to-long-run!
Ain't no thing. It's one of those things that's a lot of initial work but has the most long term benefit. If you like your API, then so will your users. It'll also help create "snapzu the platform" vs "snapzu the website". That and it's a pet peeve of mine when it's clear a site's API was developed independent of the site. ;)
Are you dogfooding this API internally? Tacking an API onto an existing site makes maintenance harder and leads to diverging features. Using the same API as your users generally leads to a nice API.
This is the ultimate test of usability. You need to make this API the tool you use for ALL of your interactions with the underlying server architecture. If you have a special set of tools whose utility outstrips that of your public-facing API, then you'll always have to replicate that work for the public sooner or later, and now you're supporting two APIs instead of one.
This is something we will be discussing at length during our next meeting. Thanks for pointing this out.
Honestly, that is one thing that has to be seriously considered. I don't care for a longer development time frame, most people can wait. We can be spoonfed, to a certain extent. I think it would be better, for devs and for users, to get some good APIs, stable and well implemented, than getting some half-assed API that breaks all the time and is hard to fix.
More work for you in the first place, but it will make our life and yours easier in the medium-to-long-run!
Ain't no thing. It's one of those things that's a lot of initial work but has the most long term benefit. If you like your API, then so will your users. It'll also help create "snapzu the platform" vs "snapzu the website". That and it's a pet peeve of mine when it's clear a site's API was developed independent of the site. ;)