Как кратко назвать RESTful API, которое, оказывается, никакое и не RESTful, ибо возвращает JSON/XML, кодов HTTP-ошибок не использует, да и URLы не те?

вижу какие-то статьи, где пишут, будто если с JSON, то это вообще не REST API!

если REST API - это когда без JSON и XML (т.е. на HTML), то какое же оно тогда API?!

Ссылки на статьи пожалуйста. Там либо автор фантазирует, либо его неправильно понимают. Единственная причина, по которой автор мог так заявить, это то, что большинство современных RESTful API не гипермедийные. Но это не значит, что не стоит в принципе использовать тот же JSON, это лишь значит, что нужно стремиться включить в него гипермедийные возможности (см. JSON-LD, HAL, Siren) и сам API также строить на этой идее, которая заключается в том, что у вас есть одна "точка входа", а на все остальные ресурсы, имеющиеся в API, вы попадаете, переходя по ссылкам внутри других возвращаемых ресурсов, точно также как вы заходите на сайт, зная его доменное имя, и дальше ходите по ссылкам.

Однако на практике пока этим пользоваться никто не умеет, гипермедийных апи сейчас единицы. Большинство апишек подразумевает чтение документации с жестко заданными URL ресурсов, по которым нужно обращаться. Ссылки же одних ресурсов на другие используются редко.

не использующее (или почти не использующее) HTTP-кодов ошибок

А вот ошибками все-таки стоит пользоваться.

какие-то паттерны URL наподобие /images/ и /images/1, про какие-то PUT и DELETE, про коды ошибок...

RESTful API и MVC — что это?

Основной посыл использования RESTful API - применение основной идеи Паутины для взаимодействия автоматических агентов (приложений), а не только людей.

Основная идея Паутины - построение распределенной информационной системы путем публикации неких абстрактных ресурсов, выдачи им идентификаторов (в сегодняшнем вебе - иерархических), определения ряда простых и широко известных операций над ними, не зависящих от содержимого ресурса (те самые GET, POST, PUT и т.д.), и связывания этих ресурсов ссылками (это называется гипермедиа, и в частности, гипертекст, если речь идет о текстовой информации).

Таким образом, если вы хотите какую-то информацию опубликовать как RESTful API, вам необходимо представить ее как набор ресурсов, а все операции над этой информацией выразить через набор предопределенных операций. Фишка в том, что во многих задачах этих предпопределенных операций вполне достаточно, главное правильно определить ресурсы.

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

Видел слово "JSON-pure API"

Это уже вкусовщина. Люди не любят XML в API за то, что его модель подходит для описания иерархических данных и документов, но не для привычных объектно-ориентированных отношений между сущностями (он-то и создавался для представления документов, а не для веб-сервисов). Поэтому популярность JSON растет до упора. Многие старые API до сих используют XML, и JSON-pure - способ похвалиться, что ваше API полностью JSON. Сама идея RESTful ничего не говорит о форматах ответа, за исключением того, что формату желательно быть гипермедийным.

REST Api базируется на одной-единственной вещи: наглядности ссылок, причем одна ссылка - одно действие. PUT \ DELETE редко используются потому, что они не везде поддерживаются, и для полной совместимости со всеми серверами и системами они заменяются POST \ GET соответственно.

И REST - не SOAP, который насквозь пропитан формализацией и протоколами (ынтерпрайз же), и должен возвращать только XML в определенном формате. REST API может отвечать так, как это требуется программисту, а json - едва ли не самый удобный способ ответа в 95% случаев.

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

/user/1/delete
/user/create
/user/1/getinfo

будет являться REST API, вне зависимости от того, какой формат будет отдавать сервер.

Ответ на вопрос: REST API.

RESTful это то что соответствует ограничениям REST, никто не обязывает Вас использовать HTTP, какие-то форматы URL, методы HTTP, json или XML. Можете хоть на почтовых голубях сообщения отправлять в формате русского матерного, и сделать на их базе RESTful API