Is it good practice for a website to use its own API?

Question

Is it good practice to develop the API while developing the site so the site itself actually uses the API? Or is there a performance hit if choosing to do this?

For example, does anyone know if mature sites such as Facebook or Digg use their own API to CRUD (Create, Read, Update, Delete) or do they have their own backend? Thanks

Answer 1

if you are using some e.g. MVC framework as a back end, then you already got some such CRUD API, or you can use something like ORB frameworks, which are directed to some sphere, as DB for example, and use their API to control your application, also its could be anything.

But I'm not advising you to use raw SQL, especially at start. so, tell me server side languages your prefer and goals of web project, and community might advice you with some new ideas.

Answer 2

I doubt Facebook and such use their own API. There are a couple of reasons not to use your own API for the site itself:

1. You can make data access more performant by using the database directly instead of doing extra requests and (de)serialization.
2. Probably easier to implement efficient caching with memcached etc
3. Importantly, you won't have to conform to your public API when extending your site (you don't want to change your public API very often, that'll just annoy everyone)

Answer 3

No, don't write your own CRUD tools or ORMS. There are enough out of the box frameworks out there where all the hard work of building API's / frameworks / utilities are already done for you - you can just reap the productivity rewards by using them. They will have also considered performance implications. The only penalty is a small learning curve for each.

That said, you can still define a standard way / practice to use these API's to ensure uniformity (and maintainability) as your app gets bigger and older.

And if you want to further protect yourself from change (or hedge your bets) you can abstract 3rd party components and frameworks by using interfaces and dependency inversion (eg. DI or service locator pattern)

Answer 4

I do think it's a good idea to have a low-level interface to the application that you can use without a browser per se, and that the site should use that interface to do its stuff.

That interface doesn't have to be the API itself, it could be a layer that's lower in level than the API, and that is used by both the API and the production website.

It's generally a bad idea if the API just duplicates the website.

i.e., the following is bad

# hypothetical example of bad duplication

def website_update_blog_post(request):
    user = request.username()
    ensure_logged_in(user)
    post = Posts.objects.upsert(request.post_title, request.post_body)
    trigger_notifications(post)

.....

def api_update_blog_post(user, password, title, body):
    verify_login(user, password)
    post = Posts.objects.upsert(title, body)
    trigger_notifications(post)