RESTful하지 않은 HTTP API를 호출하는 것은 무엇입니까? [닫은]

HTTP 기반 API를 호출하고 URI를 사용하여 리소스 이름을 지정하고 HTTP 동사 (PUT, POST, DELETE, GET ...)를 사용하여 해당 리소스를 조작 하시겠습니까?

Roy Fielding의 불만 에 따르면 하이퍼 미디어가 없기 때문에 REST가 아닙니다.

내부적으로 우리 팀에서는 누구나 "REST API"라고 부릅니다. 나는 그것을 "REST-like"라고 부르지 만 그것은 설명 적이 지 않으며 그 의미는 모호하다. REST에 대해 큰 의견 차이가 있기 때문에 혼란 스럽습니다. 나는 화염 전쟁에 참여하고 싶지 않지만 올바른 용어를 사용하십시오.

HTTP API 라고 부릅니다 .

HTTP 표준을 준수하며 맨 위에 다른 항목 (예 : SOAP)이 없습니다.

HTTP 표준은 리소스, 동사, 헤더, 콘텐츠 협상 등을 정의합니다.

REST (Representational State Transfer)는 기존 HTTP 표준을 준수해야하는 요구 사항이있는 아키텍처이지만 HTTP는 모두 자체적으로 작동합니다.

내 경험상 "REST HTTP API"의 90 %가 HTTP API를 "단지"호출해야합니다.

REST 라벨을 벗어난 것을 부끄러워하지 마십시오. 마이크로 서비스 및 비 관계형 데이터베이스와 마찬가지로, RESTful API가 없어도됩니다. Roy는 가장 오래 전부터 호환되며 네트워크로 연결된 응용 프로그램 아키텍처를 만들었습니다. 그는 좋은 일을했다. 그러나 모든 것이 40 년 이상의 호환성을 필요로하는 것은 아닙니다.

Richardson 성숙 모델은 다음과 같습니다.

0. 어디에나 게시하십시오. 단일 엔드 포인트 (비누)
1. 어디에나 게시하십시오. 여러 엔드 포인트 (자원)
2. HTTP 동사. 여러 엔드 포인트
3. 2처럼 리소스에 대한 링크를 반환합니다. (평안한)

따라서 모델에 따르면 나는 그것을 richardson 레벨 2 또는 그 라인을 따라 뭔가에 부합 하는 웹 서비스 라고 부를 것 입니다.

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

하이퍼 미디어는 결코 REST 유사 API로 인기를 얻지 못했습니다. API가 실제로 하이퍼 미디어 탐색을 구현할 때 RESTful이라는 용어는 다른 "RESTful"웹 API와 구별하기에 충분하지 않습니다. REST는 포괄적 인 용어가되거나 리소스 기반 웹 API  가되었으며 하이퍼 미디어 API 와 같은 새로운 이름이 하이퍼 미디어 개념에 집중되었습니다.

나는 잘못된 용어의 사용을 옹호하고 싶지는 않지만 REST에 대한 일반적인 현대 해석은 대부분의 사람들에게 균일 한 URL과 HTTP 동사를 사용하는 것을 의미한다고 생각합니다. 정확하지는 않지만 Fieldings 정의를 아는 사람은 다른 사람들도 그렇지 않다는 것을 알아야합니다. 반면, 기존 "RESTful"API가 구현 된 방식을 관찰하여 REST를 알고있는 사람은 HATEOAS 또는 주문형 코드와 같이 덜 알려진 REST 제한 조건을 언급 할 때 무슨 말을하는지 알 수 없습니다. 수비는 그것을 좋아하지 않을 수도 있지만, 원래의 정의로 돌아가는 것이 늦었다 고 생각합니다. 솔직하게 말하면, 누군가 자신의 REST API에 대해 처음 이야기하는 것을 들었다면 즉시 하이퍼 미디어가 포함되어 있지 않다고 가정합니까?

RESTful의 올바른 정의를 주장하면 일반적으로 추가 혼란이 발생합니다. 시간이 지남에 따라 의미가 바뀌거나 대중이 단순히 잘못 채택한 많은 용어와 마찬가지로 누군가가 원래의 정의를 알고 있지만 REST에 대한 현대적인 해석을 광범위하게 사용하는 사람은 수정하지 않을 것입니다.

_{* 또한 REST와 같은 비 하이퍼 미디어 API에 대한 새로운 용어를 설정하기 위해 늦었습니다. 어쨌든 어떻게 불러야합니까? ... 휴식 ?}

HTTP를 통한 CRUD 인터페이스 (만들기, 읽기, 업데이트, 삭제)입니다.

나는이 주장을 뒷받침 할 어떤 권위도 생각할 수 없기 때문에 더 많은 답변을 얻을 수 있기를 바랍니다.

당신이 원하는대로 부르면 사람들은 당신이 따르지 않는 REST '사양'의 어떤 부분에 (거의 종교적으로) 걸쇠를 쥐고 개발에 매우 ​​해로운 항의 지점으로 사용하는 경향이 있습니다. 그러나 간단한 사실은 API 서비스를 위해 진정한 REST를 구현하는 서비스가 거의 없다는 것입니다.

우리 팀 Stateless API은 기존의 Stateful and Functional SOAP API를 교체하고 있었기 때문에 개발 중에 있는 동안 우리의 이름을 지정했습니다. ).

이제이 프로젝트에는 단순히라는 하나의 API 만 있습니다 the <project> API. 우리가 결국 그것을 대체 할 때, 새로운 API는 단순히로 알려질 것 the new <project> API입니다.

API를 너무 많이 사용하여이 API를 나머지 API와 차별화해야하는 경우를 제외하고는 환상적이고 설명적인 내부 이름을 부여하는 것은 거의 의미가 없습니다.

웹 API 라고 부를 수 있습니다 . 매우 광범위한 용어이지만 다른 API 유형 정의의 의미에 대한 nitpicking을 피할 수 있습니다. 이 용어는 HTTP API 와 같은 대안에 비해 기술적이고 정확 하지 않지만 기술이 아닌 사람들과 대화 할 때 유리할 수 있습니다.

이 용어는 Leonard Richardson ( 이미 다른 답변으로 언급 된 Richardson 성숙도 모델 ( API가 REST 아키텍처에 얼마나 근접한 지에 대한 측정 값)을 정의 함)을 정의한)에서도 사용합니다 . " RESTful Web API " 의 "RESTful"부분을 삭제하면 얻을 수 있습니다 .