Web API design tips

I am currently developing a very simple web service and thought I could write an API for that so when I decide to expand it on ne开发者_C百科w platforms I would only have to code the parser application. That said, the API isn't meant for other developers but me, but I won't restrict access to it so anyone can build on that.

Then I thought I could even run the website itself through this API for various reasons like lower bandwidth consumption (HTML generated in browser) and client-side caching. Being AJAX heavy seemed like an even bigger reason to.

The layout looks like this:

Server (database, programming logic)
|
API (handles user reads/writes)
|
Client application (the website, browser extensions, desktop app, mobile apps)
|
Client cache (further reduces server reads)

After the introduction here are my questions:

1. Is this good use of API
2. Is it a good idea to run the whole website through the API
3. What choices for safe authentication do I have, using the API (and for some reason I prefer not to use HTTPS)

EDIT

Additional questions:

1. Any alternative approaches I haven't considered
2. What are some potential issues I haven't accounted for that may arise using this approach

First things first.

Asking if a design (or in fact anything) is "good" depends on how you define "goodness". Typical criteria are performance, maintainability, scalability, testability, reusability etc. It would help if you could add some of that context.

Having said that...

Is this good use of API

It's usually a good idea to separate out your business logic from your presentation logic and your data persistence logic. Your design does that, and therefore I'd be happy to call it "good". You might look at a formal design pattern to do this - Model View Controller is probably the current default, esp. for web applications.

Is it a good idea to run the whole website through the API

Well, that depends on the application. It's totally possible to write an application entirely in Javascript/Ajax, but there are browser compatibility issues (esp. for older browsers), and you have to build support for things users commonly expect from web applications, like deep links and search engine friendliness. If you have a well-factored API, you can do some of the page generation on the server, if that makes it easier.

What choices for safe authentication do I have, using the API (and for some reason I prefer not to use HTTPS)

Tricky one - with this kind of app, you have to distinguish between authenticating the user, and authenticating the application. For the former, OpenID or OAuth are probably the dominant solutions; for the latter, have a look at how Google requires you to sign up to use their Maps API.

In most web applications, HTTPS is not used for authentication (proving the current user is who they say they are), but for encryption. The two are related, but by no means equivalent...

Any alternative approaches I haven't considered

Maybe this fits more under question 5 - but in my experience, API design is a rather esoteric skill - it's hard for an API designer to be able to predict exactly what the client of the API is going to need. I would seriously consider writing the application without an API for your first client platform, and factor out the API later - that way, you build only what you need in the first release.

What are some potential issues I haven't accounted for that may arise using this approach

Versioning is a big deal with APIs - once you've created an interface, you can almost never change it, especially with multiple clients that you don't control. I'd build versioning in as a first class concept - with RESTful APIs, you can do this as part of the URL.

1. Is this good use of API

   Depends on what you will do with that application.

2. Is it a good idea to run the whole website through the API

   no, so your site will be accessible only through your application. this way This implementation prevents compatibility with other browsers

3. What choices for safe authentication do I have, using the API (and for some reason I prefer not to use HTTPS)

   You can use omniauth

4. Any alternative approaches I haven't considered

   create both frontends, one in your application and other in common browsers

5. What are some potential issues I haven't accounted for that may arise using this approach

   I don't now your idea, but I can't see major danger.