Если API - чистый доступ к базе данных, то разумным выбором является веб-служба REST. Он позволяет (достаточно) простой интерфейс практически с любого языка и позволяет вам выбрать любой язык, который вы считаете лучшим для написания реального веб-сервиса. Однако, делая это таким образом, вы оплачиваете стоимость дополнительного сетевого вызова за вызов API. Если вы разместите веб-службу на том же хосте (или в локальной сети), что и база данных, вы можете минимизировать стоимость сетевого вызова от веб-службы к базе данных, что снижает стоимость дополнительного вызова к API.
Если в API есть бизнес-логика, есть два подхода ...
Вы можете написать API в виде библиотеки, которую можно использовать на нескольких языках. C является хорошим выбором для этого, потому что большинство языков могут связывать библиотеки C, но языки, от которых вы ожидаете использовать его, также могут оказать большое влияние. Например, если вы знаете, что он всегда будет использоваться языком, размещенным на JVM, любой язык JVM, вероятно, является достаточно хорошим выбором.
Другой выбор - использовать гибрид двух. REST API для доступа к базе данных, а также библиотека бизнес-уровня, написанная на нескольких языках. Идея состоит в том, что у вас есть бизнес-логика на стороне приложения, но достаточно просто, чтобы вы могли написать «клиентскую библиотеку» на нескольких языках, которая знает, как вызывать REST API, а затем применять бизнес-логику к полученным результатам. , Если предположить, что бизнес-логика не слишком сложна (то есть ограничена способами объединения / просмотра данных базы данных), то это не плохое решение.
Преимущество состоит в том, что должно быть относительно легко предоставить одну библиотеку «по умолчанию», которая может использоваться многими языками, а также версии библиотеки для других языков, где у вас есть время для их реализации. В тех случаях, когда выяснение того, какие вызовы необходимо выполнить в базе данных и как объединить результаты, может быть сложным, я считаю, что это достаточно хорошее решение.