REST와 CRUD의 차이점


168

나는 REST를 배웠고 (CRUD에 대해 읽은 내용에서) CRUD와 매우 흡사합니다.

나는 그들이 다르다는 것을 알고 있으며, 그들이 비슷한 것이라고 생각하면 이해할 수 없다는 것을 궁금합니다.

REST가 CRUD의 "슈퍼 셋"입니까? CRUD가하는 모든 일 등이 있습니까?


17
그것들이 비슷한 생각은 당신 그들을 이해 한다는 것을 의미 합니다. 답을 읽을 때, 나는 놀랍고도 개념 사이의 유사성을 인정 하지 않는 잘못된 수준이라고 생각합니다 . 나는 REST를 이해하는 올바른 방법이 있다고 생각 이다 "HTTP 리소스에 대한 CRUD"로 생각 할 수 있습니다. HTTP 리소스가 무엇인지 이해하고 (데이터베이스 레코드와 분명히 같지 않음) CRUD가 무엇인지 아는 경우 REST를 "HTTP 리소스에 대한 CRUD"로 설명하는 것이 REST의 본질을 전달하는 정확하고 간결한 방법입니다.
Jason Livesay

답변:


205

놀랍게도, 나는 다른 답변에서 REST와 CRUD의 실제 차이점을 고려한 것, 즉 각각이 관리하는 것을 보지 못했습니다.

CRUD는 데이터 저장소에서 수행되는 기본 조작을 의미합니다. 레코드 또는 데이터 개체를 직접 처리합니다. 이러한 작업 외에도 레코드는 수동 엔터티입니다. 일반적으로 데이터베이스 테이블과 레코드 일뿐입니다.

반면에 REST는 각각 URL로 식별되는 자원 표시에서 작동합니다. 이들은 일반적으로 데이터 객체가 아니라 복잡한 객체 추상화입니다.

예를 들어, 리소스는 사용자의 주석 일 수 있습니다. 이는 'comment'테이블의 레코드뿐만 아니라 'user'리소스와의 관계, 주석이 첨부 된 게시물 또는 응답하는 다른 주석을 의미합니다.

주석 작업은 기본 데이터베이스 작업이 아니며 원래 포스터에 경고를 발생 시키거나 게임과 같은 '포인트'를 다시 계산하거나 '팔로어 스트림'을 업데이트하는 등의 부작용이있을 수 있습니다.

또한 리소스 표현에는 하이퍼 텍스트 ( HATEOAS 원칙 확인)가 포함되어 디자이너가 리소스 간의 관계를 표현하거나 작업 워크 플로에서 REST 클라이언트를 안내 할 수 있습니다.

간단히 말해서 CRUD는 기본적으로 설정된 기본 작업 (대부분 데이터베이스 및 정적 데이터 저장소)이며 REST는 매우 높은 수준의 API 스타일 (주로 웹 서비스 및 기타 '실시간'시스템)입니다.

첫 번째는 기본 데이터를 조작하고 다른 하나는 복잡한 시스템과 상호 작용합니다.


3
@Javier 차별화시켜 주셔서 감사합니다. 나는 REST learning Rails를 사용했으며 CRUD를 대체 한 것으로 나타났습니다 (이후에 알게 된 ... 이름은 이미 사용 중입니다. 무엇을 부르는지 몰랐습니다) ... REST vs CRUD를 2 개의 사과를 비교하는 것에서 사과와 오렌지를 비교하는 것으로 바 꾸었습니다. 감사합니다
Jesse Black

2
@Maudicus : RoR에 CRUD 계층 (대부분 (모든?) 프레임 워크와 마찬가지로)이 포함되어 있기 때문에 매우 일반적이라고 생각합니다. 그리고 그 위에 REST API를 쉽게 추가 (자동?)하면 쉽게 생각할 수 있습니다. REST가 무엇인지. 그러나 CRUD 외에 REST API 뒤에 기능을 추가하여 점점 더 다르게 만들 수 있습니다.
Javier

1
당신의 대답은 정확하지만 예제는 최적이 아닙니다. 주석은 단일 db 행으로 내려갈 수 있으며 db 트리거로 관련 객체에 대한 동적 변경을 구현할 수 없습니까? 편안한 API에는 단순한 작업이 아니라고 느끼며, 그 대답은 분명히 그 느낌을 잘 전달합니다.
didierc

2
그래서 ... 같은 것, 다른 층 :)
AlikElzin-kilaka

이것을 표현해 주셔서 감사합니다! CRUD 작업에 대한 HTTP 동사의 제한으로 인해 CRUD 상용구를 일반화하고이 사용자 정의 "주석 조작"논리의 위치를 ​​놓치는 많은 도구를 사용하여 REST를 문자 그대로 CRUD로 구현할 수 있다고 덧붙였습니다.
sompylasar

99

우선, 둘 다 단순한 이니셜입니다. 그들은 두려워 할 것이 없습니다.

이제 CRUD는 많은 응용 프로그램에서 공통적 인 기능이기 때문에 약어로 사용되는 간단한 용어이며 CRUD 를 말하기가 더 쉽습니다 . 데이터 (또는 리소스)에서 수행 할 수있는 4 가지 기본 작업에 대해 설명합니다. 작성, 읽기, 업데이트, 삭제

그러나 REST는 기술 자체가 아닌 AJAX와 같은 명명 된 사례입니다. 오랫동안 HTTP 프로토콜에 내재되어 있지만 거의 사용되지 않는 기능을 사용하도록 권장합니다.

URL (Uniform Resource Locator )이 있고 주소 표시 줄로 브라우저를 가리키면 HTTP 요청 이 전송 됩니다. 각 HTTP 요청에는 서버가 요청을 발행 한 클라이언트에게 다시 보낼 HTTP 응답 을 알기 위해 사용할 수있는 정보가 포함되어 있습니다 .

각 요청에는 URL이 포함되어 있으므로 서버는 액세스하려는 리소스 를 알고 있지만 method 도 포함 할 수 있습니다 . 메소드는 해당 자원 으로 수행작업 을 설명합니다.

그러나이 "방법"개념은 자주 사용되지 않았습니다.

일반적으로 사람들은 GET 메소드를 통해 페이지에 링크 하고 POST 메소드를 통해 모든 유형의 업데이트 (삭제, 삽입, 업데이트)를 발행 합니다 .

그리고 그 때문에 하나의 리소스 (URL)를 실제 리소스로 취급 할 수 없었 습니다. 동일한 리소스를 삭제, 삽입 또는 업데이트하려면 별도의 URL이 있어야합니다. 예를 들면 다음과 같습니다.

http://...com/posts/create- POST request  -> Goes to posts.create() method in the server
http://...com/posts/1/show- GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1/delete - POST request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1/edit- POST request  -> Goes to posts.edit(1) method in the server

REST를 사용하면 POST 외에 다른 HTTP 메소드를 사용하기 때문에 더 똑똑한 양식을 작성 하고 URL뿐만 아니라 메소드 를 구별 할 수 있도록 서버를 프로그래밍하십시오 . 예를 들어 :

http://...com/posts - POST request  -> Goes to posts.create() method in the server
http://...com/posts/1 - GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1 - DELETE request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1 - PUT request  -> Goes to posts.edit(1) method in the server

단일 URL은 단일 리소스를 설명합니다. 단일 게시물은 단일 리소스입니다. REST를 사용하면 자원을 처리하려는 방식으로 처리합니다. 처리하려는 리소스와 처리 방법을 서버에 알려줍니다.

"RESTful architecture"에는 다른 많은 기능이 있으며, 관심이 있다면 Wikipedia, 다른 기사 또는 서적에서 읽을 수 있습니다. 반면에 CRUD 자체에는 더 많은 것이 없습니다.


4
죄송하지만 REST CRUD 이상입니다. 리소스는 각각 하나 이상의 레코드를 구현하기 때문에 각 작업은 레코드를 업데이트하는 것 이상의 역할을하기 때문입니다.
Javier

11
승인. 동의한다. 왜 당신이 미안해합니까? 나는 그것이 CRUD보다 많지 않다고 말하지 않았다. 나는 내가 정확히 무엇을 생각 않았다 말한다.
얌 마르코비치

4
이것이 정답이어야합니다.
Brandon

HTML 사양에서는 양식 제출을 위해 GET 및 POST 메소드 만 허용하므로 AJAX가 널리 보급되기 전에 다른 메소드는 웹 클라이언트의 요청을 처리하는 서비스에 사용되지 않았습니다. 일부 서비스는 POST 메소드를 사용하여 양식을 제출하는 동안 POST 이외의 메소드를 지정하기위한 임시 해결책으로 이름이 "_method"인 숨겨진 입력 필드를 사용합니다.
Kenneth Sundqvist

20

REST는 "표현 상태 전송"을 나타내며, 이는 시스템에서 일부 자원의 상태를 통신하고 수정하는 것입니다.

REST의 이론은 미디어, 하이퍼 미디어 및 기본 프로토콜을 활용하여 원격 시스템의 정보를 관리하기 때문에 REST가 상당히 관여합니다.

반면에 CRUD는 데이터베이스의 데이터에 필요한 일반 작업에 대한 니모닉입니다. Create Retrieve Update Delete. 그러나 그것은 실제로 그것보다 더 깊어지지 않습니다.

이것이 귀하의 질문에 대한 답변이지만 REST와 CRUD가 함께 논의 될 때 나는 일반적인 실수를 언급 할 것입니다. HTTP를 통한 REST는 GET PUT POST 및 DELETE를 제공하고 CRUD는 CREATE RETRIEVE UPDATE DELETE를 제공하므로 많은 개발자가 REST를 CRUD에 직접 맵핑하려고합니다. REST 동사를 CRUD 오퍼레이션에 직접 맵핑하는 것이 당연합니다.

그러나 HTTP는 "작성 또는 업데이트"스타일을 사용하지만 CRUD는 작성 및 업데이트를 분리합니다. 따라서 두 개 (!) 사이를 깨끗하고 일반적인 매핑을 만드는 것은 불가능합니다 (!).

GET과 DELETE는 쉽다 ... GET === RETRIEVE, DELETE === DELETE.

그러나 HTTP 사양에 따라 PUT은 실제로 작성 및 업데이트입니다.

  • PUT을 사용하여 식별자를 포함하여 모든 것을 알면 완전히 새로운 객체를 만듭니다.

  • PUT을 사용하여 객체를 업데이트합니다 (일반적으로 객체를 완전히 표시 함)

POST는 "처리 중"동사이며 "추가"동사로 간주됩니다.

  • POST를 사용하여 컬렉션에 새 개체를 추가합니다. 즉, 새 개체를 만듭니다

  • HTTP 사양에 따라 "데이터 처리"동사로 정의되므로 다른 동사 중 어느 것도 적합하지 않은 경우에도 POST가 사용됩니다.

  • 팀이 POST에 전화를 끊는 경우 WWW 전체가 GET 및 POST를 기반으로 구축되었습니다.

REST와 CRUD가 유사하지만 대부분의 팀이 저지르는 실수는 둘 사이에서 동등성을 만드는 것입니다. 실제로 REST API를 정의 할 때 CRUD 니모닉에 걸리지 않도록주의해야합니다. 실제로 REST는 CRUD에 명확하게 맵핑되지 않는 추가 복잡성이 많기 때문입니다.


7

CRUD는 데이터 읽기 및 쓰기를위한 최소 기본 스토리지 동사 세트 (생성, 읽기, 업데이트 및 삭제)를 지정합니다. 그런 다음이를 집계하여 다른 오퍼레이션을 빌드 할 수 있습니다. 이들은 일반적으로 데이터베이스 작업으로 간주되지만 데이터베이스로 간주되는 것은 임의적입니다 (예 : 관계형 DBMS 일 수도 있지만 YAML 파일 일 수도 있음).

REST는 일반적으로 CRUD 오퍼레이션 및 기타 상위 레벨 오퍼레이션을 포함하는 "아키텍처 스타일"로, 일부 "리소스"개념 (임의이지만 애플리케이션의 엔티티)에서 수행됩니다. REST에는 흥미롭고 특히 HTTP와 잘 어울리는 제약 조건 이 있습니다.

REST 인터페이스는 특정 자원에 대한 모든 CRUD 조작을 노출 할 수 있지만 반드시 그럴 필요는 없습니다. REST 인터페이스에서 사용할 수있는 것은 임의적이며 시스템 권한, UI 고려 사항 및 인터페이스가 설계되고 작성된 날의 시스템 온도에 따라 변경 될 수 있습니다. 더 뜨거운 날은 더 미니멀 한 인터페이스로 이어지지 만, 그 반대 일 수도 있습니다.


고마워요 "CRUD가하는 모든 일과 그 이상이 있습니까?" 예, REST 기술은 데이터베이스의 단순한 항목 이상에 적용됩니다.
Jesse Black

@Maudicus 나는 대답을 업데이트했지만 구체적으로 설명했다.
Dan Rosenstark

귀하의 신청서가 완료된 것으로 간주 될 필요는 없습니다. 일부 응용 프로그램은 본질적으로 삽입, 제거 또는 업데이트가 필요하지 않습니다.
얌 마르코비치

@Yam Marcovic은, 좋아, 조정
댄 Rosenstark는을

6

CRUD

  • CRUD는 네 가지 기본 SQL 명령 유형입니다. 작성, 읽기, 업데이트 및 삭제
  • 대부분의 응용 프로그램에는 일종의 CRUD 기능이 있습니다
  • CRUD 응용 프로그램은 양식을 사용하여 데이터베이스에 데이터를 가져오고 내보내는 응용 프로그램입니다.

쉬다

  • REST는 Representational State Transfer (Representational State Transfer)의 약자입니다 (때로는 "ReST"로 표기 됨).

  • 상태 비 저장 클라이언트 서버 캐시 가능 통신 프로토콜에 의존하며 사실상 모든 경우에 HTTP 프로토콜이 사용됩니다.

  • REST는 네트워크 애플리케이션 설계를위한 아키텍처 스타일입니다


2

REST는 머신을위한 웹 페이지와 같은 것으로, CRUD는 클라이언트와 강력하게 연결된 SOAP와 같은 것입니다. 이것이 주요 차이점입니다. Ofc. 그것들은 표면 상 비슷하지만 CRUD는 기본 엔티티 조작을 설명하고 REST는 모든 애플리케이션의 인터페이스를 설명 할 수 있습니다. REST가 더 많은 4 가지 HTTP 메소드를 사용할 수 있다는 또 다른 차이점입니다. 모든 차이점을 수집하고 싶다면 REST 대 SOAP에 대한 질문을 확인하면 대부분의 답변을 얻을 수 있습니다.

REST와 CRUD를 혼동하는 것은 매우 일반적인 실수이며 개발자가 REST에 대해 깊이 읽을 시간이 없기 때문입니다. 그들은 유사한 개발자가 작성한 제한된 CRUD 스타일 예제를 기반으로 이해하지 않고 기술을 사용하려고합니다. 예제와 튜토리얼의 대다수는 심각한 지식 부족을 반영하고 있습니다. 엔티티에 REST 자원을 맵핑하고 이러한 엔티티의 CRUD 조작에 HTTP 메소드를 맵핑하고 하이퍼 링크없이 REST를 사용하는 것은 단지 증상입니다. REST를 통해 하이퍼 링크 (POST / PUT / DELETE / PATCH 메소드가 포함 된 링크 포함)를 조작에 맵핑하고 (일반적으로 API 별) 링크 관계를 확인하여 클라이언트 측에서 조작을 식별합니다. REST 클라이언트가 링크 관계가 무엇인지 모르고 HTTP 메소드 및 일부 URI 템플리트 만 알고있는 경우, 그러면 REST 클라이언트가 아니라 HTTP 클라이언트의 CRUD입니다. REST 클라이언트가 브라우저에서 실행되는 단일 페이지 Javascript 애플리케이션이라는 또 다른 일반적인 실수입니다. 물론 이러한 클라이언트를 구현할 수 있지만 REST는 주로 자동 클라이언트 (알지 못하는 개발자가 작성한 서버 측 애플리케이션)를위한 것이지 수동 클라이언트 (사용자가 작성한 사용자 제어 브라우저 애플리케이션)를위한 것이 아닙니다. 브라우저 클라이언트가 하나만 있으면 실제로 REST가 필요하지 않고 프로젝트를 과도하게 엔지니어링했다는 신호일 수 있습니다. 이 경우 CRUD API는 실행 가능한 솔루션이며 개발자는 이러한 CRUD API를 차이로 알지 못하기 때문에 REST로 호출합니다. 물론 이러한 클라이언트를 구현할 수 있지만 REST는 주로 자동 클라이언트 (알지 못하는 개발자가 작성한 서버 측 애플리케이션)를위한 것이지 수동 클라이언트 (사용자가 작성한 사용자 제어 브라우저 애플리케이션)를위한 것이 아닙니다. 브라우저 클라이언트가 하나만 있으면 실제로 REST가 필요하지 않고 프로젝트를 과도하게 엔지니어링했다는 신호일 수 있습니다. 이 경우 CRUD API는 실행 가능한 솔루션이며 개발자는 이러한 CRUD API를 차이로 알지 못하기 때문에 REST로 호출합니다. 물론 이러한 클라이언트를 구현할 수 있지만 REST는 주로 자동 클라이언트 (알지 못하는 개발자가 작성한 서버 측 애플리케이션)를위한 것이지 수동 클라이언트 (사용자가 작성한 사용자 제어 브라우저 애플리케이션)를위한 것이 아닙니다. 브라우저 클라이언트가 하나만 있으면 실제로 REST가 필요하지 않고 프로젝트를 과도하게 엔지니어링했다는 신호일 수 있습니다. 이 경우 CRUD API는 실행 가능한 솔루션이며 개발자는 이러한 CRUD API를 차이로 알지 못하기 때문에 REST로 호출합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.