Эдуард Тибет

Уже был подобный вопрос. Ответ тут: Как правильно вести техническую документацию Системному администратору?

Сначала вам сюда: Как и где хранить техническую документацию?

Потом появятся уточняющий вопросы.

Общий подход: docs-as-code. Поищите в сети.
Реализация: тысячи их. Выберите, что вам подходит.

Но если хотите сделать все по уму, то сначала вам сюда: Как и где хранить техническую документацию?

Начинаем отсюда: Как и где хранить техническую документацию? (пусть вас не смущает название темы) и читаем, читаем, читаем. На очень многие вопросы уже отвечено.

Если не хотите тыкать пальцем в небо, а нужен системный подход без факапов, начните изучать тему отсюда: Как лучше сделать документацию компании? и далее по ссылкам в том посте.

P.S. Неоднократно замечаю интересный факт. Все советуют решение, о котором вроде бы слышали или которое работает конкретно у них, но никто не задается главным вопросом: а какая цель у ТС? Какие входные условия у ТС? Участники треда, вы понимаете, что выбор инструмента/подхода - это не выбор из А, B, C. Это, в первую очередь, определение цели (они могут различаться на 180 град.), анализ входных условий и только потом выбор инструмента/подхода. Если у конкретного участника этого топика работает инструмент/подход, который приносит ему пользу, то это совсем НЕ означает, что такой же подход с таким же успехом будет обязательно работать у топикстартера.

Можно выбрать тут.

Если вам именно Маркдаун, посмотрите на проект Фолиант: https://github.com/foliant-docs/foliant

Что должна включать в себя главная страница документации, чтобы она была максимально структурированная, легка для поиска нужной информации, чтобы слету понимать, что, где, и как? И просто удобна с точки зрения юзабилити.
Накидайте пожалуйста ссылок на реально качественную документацию.

Опять не вижу главного - цели? Какие у вас цели? Почему все задают вопросы Как? не определяя изначального Зачем?

чтобы слету понимать, что, где, и как

В зависимости от ЦА - цели разные. Поэтому уточните параметры, что вы хотите получить в итоге? Допустим, я хочу, чтобы разработчик А находил нужный ответ за время X. Или я хочу, чтобы человек сразу увидел, что у нас крутой продукт и захотел его купить (заказать сервис с его использованием).

Просто подобрать подходящий интернет ресурс и написать администрации касательно этого?

Да, причем в несколько сразу. Они, скорее всего, запросят у вас abstract, чтобы понять о чем речь. Можно также попробовать податься в университетские издания (USA & EU) - т.е. то, что называется academics.

ekizare

Вы изначально неправильно подходите к вопросу, т.к. не совсем ясна цель. Список требований (небольшой) у вас есть, а цели нет.

Тогда начинаем отсюда: Как лучше сделать документацию компании? и постепенно строим картину у себя в голове.

IvanN777 , чтобы привести свои мысли в порядок, начните с этого ответа: Как лучше сделать документацию компании?

Я уже отвечал в свое время на подобный вопрос. Посмотрите тут: Где сисадмину хранить документацию и конфиги серверов, а также собственные наблюдения и размышления?

Ринат Бакиев

Вам нужна технология единого источника. Там вы держите всю информацию отдельно и собираете только финальный выход. Т.е. вы физически (на уровне прав доступа) можете разделить каждый документ на куски информации и поместить их в свои репо, которое будет доступно каждому конкретному члену команды.

Также подобное можно реализовать с помощью lightweight markup languages (md, rst, adoc). Все зависит от того, какой процент документации у вас пишут девелоперы, а какой - другие участники команды. Чем больше dev - тем более lml.

Вопросы - задавайте.

Все зависит от того:

1. Справочник по какому именно API? REST? Или другое? Ведь API много разных на свете.

2. Если REST, то нужен ли вам интерактив или text only?

ТС - а каким боком к этому вопросу относится тег "документация"???

Подойдет? https://github.com/sourcey/moxygen