Как назвать HTTP API, который не является RESTful? [закрыто]

Как бы вы назвали API, основанный на HTTP, использующий URI для именования ресурсов и HTTP-глаголы (PUT, POST, DELETE, GET ...) для управления этими ресурсами?

Согласно жалобам Роя Филдинга, это не ОТДЫХ, потому что нет гипермедиа.

Внутренне, в моей команде, все называют это «REST API». Я называю это «REST-like», но оно не носит описательный характер, а его значение размыто. Я совершенно сбит с толку, потому что существует огромное разногласие по поводу REST. Я не хочу участвовать в огненных войнах, но просто использую правильные термины.

Назовите это HTTP API .

Он соответствует стандартам HTTP и не имеет ничего более верхнего слоя (например, SOAP).

Стандарты HTTP определяют ресурсы, глаголы, заголовки, согласование содержимого и т. Д.

REST (REpresentational State Transfer) - это архитектура с требованиями, которые соответствуют существующим стандартам HTTP, но HTTP работает самостоятельно.

По моему опыту, 90% «API REST HTTP» должны называть себя «просто» HTTP API.

Не стыдно оставить ярлык REST. Как и в случае с микросервисами и нереляционными базами данных, вам не нужно иметь RESTful API, чтобы быть крутым. Рой намеревался создать самую долгоживущую, наиболее обратно совместимую архитектуру сетевых приложений, какую только мог. Он хорошо поработал. Но не всем нужно более 40 лет совместимости.

Модели зрелости Ричардсона идут как это

0. ПОСТ везде. Единственная конечная точка. (МЫЛО)
1. ПОСТ везде. Несколько конечных точек. (Ресурсы)
2. HTTP VERBS. Несколько конечных точек.
3. Нравится 2 и возвращает ссылки на ресурсы. (RESTful)

Поэтому в соответствии с моделью я бы назвал это веб-сервисом, соответствующим уровню Ричардсона 2, или чем-то в этом роде.

http://martinfowler.com/articles/richardsonMaturityModel.html

Hypermedia никогда не пользовалась популярностью среди REST-подобных API - до такой степени, что когда API фактически реализует гипермедиа-навигацию, термина RESTful просто недостаточно, чтобы отличить его от любых других «RESTful» веб-API. REST стал универсальным термином или любым веб-API на основе ресурсов, а новые имена, такие как Hypermedia API  , были придуманы, чтобы сосредоточиться на концепции гипермедиа.

Я действительно не хочу защищать использование неправильных терминов, но я думаю, что общая современная интерпретация REST просто означает использование унифицированных URL и HTTP-глаголов для большинства людей. Это не правильно, но любой, кто знает определение Филдинга, также должен знать, что многие другие не знают. С другой стороны, любой, кто знает REST только наблюдая за тем, как реализованы существующие API-интерфейсы RESTful, не поймет, о чем идет речь, когда вы упомянете менее известные ограничения REST, такие как HATEOAS или код по требованию. Филдинг может не понравиться, но я думаю, что уже поздно возвращаться к первоначальному определению *. И давайте будем честными: если вы впервые слышите, как кто-то говорит о его REST API, вы сразу же предполагаете, что он не включает гипермедиа, не так ли?

Настаивание на правильном определении RESTful обычно только создает дополнительную путаницу. Как и со многими терминами, которые со временем изменили свое значение или которые массы просто приняли неправильно, я ценю, если кто-то знает первоначальное определение, но я не исправлю никого, кто использует более широкую современную интерпретацию REST.

_{* а также в конце, чтобы установить новые термины для API, не относящихся к гипермедиа, как REST. Как мы должны их называть? ... восстановить ?}

Это интерфейс CRUD (создание, чтение, обновление, удаление) по HTTP.

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

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

В нашей команде мы назвали наше, Stateless APIпока оно находилось в стадии разработки, потому что у нас был устаревший Stateful и функциональный API-интерфейс SOAP, который мы заменяли (у самого старого API никогда не было согласованного и значимого имени, поэтому мы не слишком увлеклись именами ).

Теперь у этого проекта есть только один API, который называется просто the <project> API. Когда мы в конечном итоге заменим его, новый API будет просто известен как the new <project> API.

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

Вы можете назвать это веб-API . Это очень широкий термин, но он может избежать придирки к смыслу других определений типов API. Этот термин менее технический и точный по сравнению с альтернативами, такими как HTTP API , но это может быть преимуществом при общении с нетехническими людьми.

Этот термин также используется Леонардом Ричардсоном (который определил модель зрелости Ричардсона, на которую уже упоминался другой ответ - хорошо принятый показатель того, насколько API близок к архитектуре REST). Это то, что вы получаете, если отбрасываете часть «RESTful» в « RESTful Web API ».