This is an interesting question, and not very easy to answer. It depends on what website you are developing, in order to justify the effort in any direction. Here is my opinion for some of your points:

Using the API for everything: Disadvantages

• Lots of HTTP requests to the API

This depends on whether you are developing a standard website or one that should be accessible extensively via mobile devices. It makes sense to use smaller in portions, but more frequent communication in case when the client is a mobile device. Mobile devices have limited capabilities in terms of hardware and could also have slower internet connection. A large server response may take significant time to be processed on the device itself.

• The website will break if the API goes down

Well, that is a problem of the website, not the API. The website must be developed with caution to the case when the API is not available. This could be a real-life scenario, as if the API is being updated and redeployed, the site would experience a downtime and not work. Regardless of whether entirely depending on the API or not, you must provide means for graceful error handling – show a suitable error page, or limit the functionality accordingly.

• The website rendering time will be slower (will use ajax)

I disagree. AJAX actually causes the site to load faster. Each AJAX request, if made asynchronous, would render a separate portion of the site. If you were to wait for all portions to load at once, the cumulative loading time would hardly differ. Besides, almost everyone uses AJAX today, and this has proven to not be an issue, if properly done. Additionally, AJAX is extensively used to bring some processing to the client, not the server – this is usually employed as a technique to reduce server load.

Using the API when needed: Disadvantages

• I’ll have to manage user authentication, permissions and relations to his objects in the API

If that is a concern to you, I mean if you need to do the user authentication and security by youtself, then you should not rely on the API entirely. It is often the case that people develop their own system and maintain both the local and the remote (the API’s) accounts at once – the concept of linked accounts. It is popular approach for system with already existing users to provide means for linking the user account with, for instance, the user’s facebook account.
If you want have your own user account information, but are reluctant to manage the authentication and authorization yourself, consider using OpenID if the API supports it, or consider implementing one, if you are developing the API too.

• Duplicate user data in my database and the API (I’ll have a copy of the user objects)

As per the above point, it is inevitable to have some data repeated. If the user object to your project means something different to you than the user from the API, then you must manage this information yourself.

• Worried about the data sync (I’ll update the database only on create/update/delete requests to the API)

Maintaining two distinct systems in sync is something that has always been a serious development effort. If you can avoid this, and rely entirely on the API, you’d probably prefer the API approach. If the API does not provide you with all the capabilities for your own project, then you could still have to face this maintenance task.

In addition to your concerns, you need to consider some additional ones:

• Does the API guarantee backwards compatibility if they introduce changes?
• Is the API documented well enough so you can cover the aspects of your project with it entirely?
• How does one introduce fixes/improvements to the API? There are serious differences between maintaining and improving OpenSource projects/APIs and commercial ones. Also, any project usually has its own policy to when is appropriate to apply certain fixes and changes (most open source projects will do this faster than a commercial product, that is not to say fast enough for you). This is something to consider if you discover a problem with the API that breaks your code. If this is not seen to be fixed by the API’s team, you would be on your own for working this around.

It is sometimes acceptable to not directly use the external API, but create a wrapping API that is what you would directly use for your project. Then delegate the API availability and compatibility problems to your API wrapper. That way, changes will not directly affect the website, or any other application that consumes it. You will also have the freedom to expose the external API in a form that is more suitable. For example, you may expose a single method that results in multiple calls to the external API – so you will reduce the number of requests the website does.

As a bottom line, the real concerns you may have is the data duplication and the site availability in case of API crash or incompatible changes. I would decide based on the estimated development effort with either approach, and the likeability of problems with that approach.