Как именовать методы api web-сервисов.

Поменяй теги, CGI здесь вообще не при чем. Даже я — любитель сишечки — уже давно перестал в новых поделках использовать CGI, теперь у меня непосредственно сетевые демоны, которые либо напрямую обрабатывают POST/GET запросы на определенный непривилегированный порт, либо работают через вебсокеты. Еще можно проксировать запросы nginx'ом (т.н. fastcgi), но это вообще не CGI как таковые.

Что до стандартов, сильно сомневаюсь, что они есть. Каждый лепит как ему нравится.

На расширение всем наплевать. Можете сделать хоть /cgi-bin/query.exe, если того ожидают уже существующие клиенты. Если требований обратной совместимости нет, а возможности того позволяют, делайте вовсе без расширения.

Зачем вообще расширение? Делай просто /api/hi.

Хм, я думал, ТС имеет в виду именно «расширение», а не суффикс пути запроса.

Ну и писал бы «суффикс»!..

Если речь не о CRUD, то в общем случае у меня будет так: /api/<версия>/<категория>/<метод>

Например: /api/0.1/employees/promote

Если на кой-то чёрт (очень хочется сделать крайне всратые балансировку и кеширование, допустим) стараться делать поближе к REST, то прямо в урле ещё будет идентификатор ресурса: /api/0.1/employees/1033/promote

Когда-то давно, когда я был молод и глуп, и не видал больших... проектов, то я примерно так же искал гайды по организации тэгов у информации. А гайд очень простой: собираешь информацию, и далее пост фактум организовываешь ее. Хуже отсутствия организации может быть только неправильная организация.

Вообще, правилом хорошего тона является либо не использовать расширения вообще (/api/blahblah), либо использовать соответствующие твоему формату данных (/api/blahblah.json, /api/blahblah.xml, или что там у тебя).

С другой стороны, если у тебя уже есть апи, которым кто-то пользуется – сделай пользователю хорошо, ничего в нем не меняй.

У меня как раз сейчас выбор есть сделать «как правильно»

но тут я решил переписать все на python и соответственно url будет как-то дезорганизовывать пользователя

Пользователю веб-сервиса нет дела до деталей его реализации. Но суффикс лучше вообще убрать. Суффиксы .json/.xml я бы тоже не стал использовать, такие вещи лучше через параметры делать. В пути метода (до параметров) вообще лучше никогда ничего не менять, кроме версии API, которую тебе стоило бы добавить. Её всегда стоит добавлять, даже если кажется, что версий не будет.

Ок. Это учту. Есть литература с пруфами, уже пару раз встречал такой подход. Откуда пошло?

Не знаю, просто делюсь опытом. Имею дело с некоторым количеством разнообразных сервисов, также разрабатывал свои. Мне кажется, это просто здравый смысл.