O que chamar de uma API HTTP que não é RESTful? [fechadas]

O que você chamaria de uma API baseada em HTTP, usa URI para nomear recursos e verbos HTTP (PUT, POST, DELETE, GET ...) para manipular esses recursos?

Segundo as queixas de Roy Fielding, não é REST, porque não há hipermídia.

Internamente, na minha equipe, todos chamam de "API REST". Eu o chamo de "tipo REST", mas não é descritivo e seu significado é confuso. Estou bastante confuso sobre isso, já que há uma grande discordância sobre o REST. Não quero participar de guerras de chamas, mas apenas usando termos corretos.

Chame isso de API HTTP .

Está em conformidade com os padrões HTTP e não possui mais nada em camadas (por exemplo, SOAP).

Os padrões HTTP definem recursos, verbos, cabeçalhos, negociação de conteúdo etc.

O REST (REpresentational State Transfer) é uma arquitetura com requisitos que são adequados aos padrões HTTP existentes, mas o HTTP funciona por si só.

Na minha experiência, 90% das "APIs HTTP REST" devem se chamar "apenas" uma API HTTP.

Não tenha vergonha de deixar de lado o rótulo REST. Assim como nos microsserviços e bancos de dados não relacionais, você não precisa ter uma API RESTful para ser legal. Roy se propôs a criar a arquitetura de aplicativos em rede mais durável e compatível com versões anteriores que ele pudesse. Ele fez um bom trabalho. Mas nem tudo precisa de mais de 40 anos de compatibilidade.

Richardson Maturity Models é mais ou menos assim

0. POST em todos os lugares. Um único terminal. (SABONETE)
1. POST em todos os lugares. Vários pontos finais. (Recursos)
2. VERBOS HTTP. Vários pontos finais.
3. Gosto de 2 e retorna links para recursos. (Repousante)

Então, de acordo com o modelo, eu o chamaria de serviço da web em conformidade com o nível 2 de Richardson ou algo assim.

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

A hipermídia nunca ficou realmente popular com APIs do tipo REST - a ponto de quando uma API realmente implementa a navegação hipermídia, o termo RESTful simplesmente não é suficiente para distingui-la de outras APIs da web "RESTful". O REST se tornou um termo genérico ou qualquer API da Web baseada em recursos e novos nomes como a API Hypermedia  foram criados para se concentrar no conceito de hipermídia.

Eu realmente não quero defender o uso de termos incorretos, mas acho que a interpretação moderna geral do REST significa simplesmente usar URLs uniformes e verbos HTTP para a maioria das pessoas. Não está correto, mas quem conhece a definição de Fieldings também deve saber que muitos outros não. Por outro lado, quem conhece o REST apenas observando como as APIs "RESTful" existentes são implementadas, não saberá do que está falando quando mencionar restrições REST menos conhecidas, como HATEOAS ou código sob demanda. Fielding pode não gostar, mas acho que é tarde para voltar à definição original *. E sejamos honestos: se você ouvir alguém falar sobre sua API REST pela primeira vez, presume instantaneamente que ela não inclui hipermídia, não é?

Insistir na definição correta de RESTful geralmente cria apenas confusão adicional. Como ocorre com muitos termos que mudaram de significado ao longo do tempo ou que as massas simplesmente adotaram de forma errada, eu aprecio se alguém conhece a definição original, mas eu não corrijo quem estiver usando a interpretação moderna mais ampla do REST.

_{* e também tarde demais para estabelecer novos termos para APIs não hipermídia semelhantes a REST. Como devemos chamá-los de qualquer maneira? ... RESTish ?}

É uma interface CRUD (Criar, Ler, Atualizar, Excluir) sobre HTTP.

Não consigo pensar em nenhuma autoridade para apoiar essa afirmação, então espero que você obtenha mais e melhores respostas.

Você pode chamá-lo como quiser, as pessoas tendem a (quase religiosamente) se prender a qualquer parte das 'especificações' do REST que você não está seguindo e usar isso como um ponto de protesto que é altamente prejudicial ao desenvolvimento. Mas dito isso, o simples fato é que existem (quase) zero serviços que implementam o verdadeiro REST para seus serviços de API.

Em nossa equipe, nomeamos a nossa Stateless APIenquanto ela estava em desenvolvimento, porque tínhamos uma API SOAP stateful e funcional herdada que estávamos substituindo (a própria API herdada nunca teve um nome significativo e acordado, portanto não ficamos muito envolvidos em nomes )

Agora, este projeto tem apenas uma API que é chamada simplesmente the <project> API. Quando a substituirmos, a nova API será conhecida como the new <project> API.

Dar a ele qualquer nome interno sofisticado e descritivo é quase sem sentido, a menos que você tenha tantas APIs que precise diferenciá-la das demais (nesse caso, você provavelmente também deve renomear todas as outras).

Você pode chamá-lo de API da Web . É um termo muito amplo, mas pode evitar falar sobre o significado de outras definições de tipo de API. O termo é menos técnico e preciso em comparação com alternativas como a API HTTP , mas isso pode ser uma vantagem quando se fala de pessoas não técnicas.

Esse termo também é usado por Leonard Richardson (que definiu o Richardson Maturity Model que já foi mencionado outra resposta - uma medida bem aceita para a proximidade da API de uma arquitetura REST). É o que você obtém se você soltar a parte "RESTful" de uma " API Web RESTful ".