вижу какие-то статьи, где пишут, будто если с 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 ничего не говорит о форматах ответа, за исключением того, что формату желательно быть гипермедийным.
