Which is better: {REST API, website} --> {database}, or {website} --> {REST API} --> {database}?

I have a product that gathers and displays measurements of all kinds (won't go into it). The display portion is, as one would expect, a database + website built on top of it (with Symfony).

However, we'll probably be creating an API to expose the data to third-parties as well.

Now, we either have the choice of building both the website and the API on top of the database, or just build the API on top, and have the website implement the API.

I would greatly prefer the latter, since otherwise I'll have to adapt both model layers for the API and the website every time the schema changes (which can be a few times). If I have the latter I obviously have the advantage of only adapting the API model. If the API contract stays the same, the website wouldn't need adapting.

However, obviously there is a downside in performance. With website <-> database, vs website <-> API <-> database, the first will obviously be the fastest.

My question is: what is your opinion on this trade-off? I'm hoping the performance can be almost evened out, since all the machines will be on the same LAN + there will be caching. If that's the case, the ease of development would certainly make my life ea开发者_开发百科sier :-)

Looking forward to your opinions and experience!

---

If there was ever a case of premature optimization, this is it! You're not going to know the answer without more information, and I suspect very much that the performance differences between the two will be so negligible as to be irrelevant in your domain.

The best approach, IMO, is to spike on a few of your models using both approaches and see where that gets you.

---

No better way to make sure your API is going to be usable by others than to use it yourself. I would go website -> API -> database. Write it once, you can always tune it and "cheat" later if you have too.

---

Many modern websites use JavaScript (AJAX etc) and then make service calls to an API. If you took that approach you would simply have a carefully designed, reusable API layer in front of your DB.

I find that there's little or no extra effort here, and I'm sceptical that you'll incur noticable performance penalties.