REST API -2 REST, SOAP

[Dev Knowledge] - REST API -1 Service, Protocol(SOAP)

REST API -1 Service, Protocol(SOAP)

위에 링크된 이전 포스팅에서는 SOAP까지 살펴 보았었죠,  이번 포스팅에서는 REST에 대해서 살펴보고 

SOAP과 REST를 간략하게 그림으로 보여드리려고 합니다. 말씀 드렸듯이, 같은 선상에 놓여진 두개의 프로토콜이 아니기 때문에 직접적으로 비교하기는 그렇지만, 저에게 이해에 도움이 되었었던 그림을 넣어보려구 합니다.

 

 

REST

REST는, 

 

..??

 

이게 아니구요 ㅋㅋㅋ

REST는 HTTP 프로토콜로 데이터를 전달하는 프레임워크라고 생각하시면 됩니다. 또한 클라이언트/서버 간의 구성요소를 엄격히 분리하여 구현은 단순화시키고 확장성과 성능은 높일 수 있는 아키텍처입니다.

 

여기서 리소스 (resource)란 REST 아키텍처의 핵심 요소로서 웹 사이트, 블로그, 이미지, 음악, 이용자, 지도, 검색 결 과 등 웹에서 다른 이들과 공유하고자 개방된 모든 자원을 의미 합니다.

REST Architecture

 

REST 구조에서의 리소스는 그들 의 고유한 URI를 가지며, HTTP의 기본 메소드인 GET/PUT/POST/DELETE 으로 접근할 수 있습니다.

 

특징 중 하나는, REST API는 상태를 저장하지 않습니다. 때문에 호출이 서로 독립적으로 이루어질 수 있으며 각 호출에는 성공적으로 완료하는 데 필요한 모든 데이터가 포함됩니다. REST API는 호출로 수행 할 작업을 결정하기 위해 서버 또는 세션에 저장된 데이터에 의존해서는 안되며, 호출 자체에서 제공되는 데이터에만 의존해야합니다. 대신 각 호출에는 API 키, 액세스 토큰, 사용자 ID 등과 같은 필요한 데이터가 포함됩니다.

 

 

REST의 CRUD Operation 입니다. 위에서 언급 했듯이, POST, GET , PUT, DELETE가 있습니다. 아래의 표로 정리 해 보았습니다.

위의 CURD 를 사용하여, URL은 아래와 같이 이루어 질 수 있습니다

• GET tasks/messages - task에 대한 message들의 목록을 검색
• GET tasks/messages/10 - task에 대한 message 10번을 검색
• POST tasks/messages - task에 새로운 message를 등록
• DELETE tasks/messages/10 - task의 10번 message를 삭제
• PUT tasks/messages/12 - task의 12번 message를 수정

따라서 REST API를 사용 할 경우에는, 직관적이고 알기 쉽게 구조화 해야 합니다.

 

대부분 POST로만 구현 할 수도 있지만, 그렇게 되면 RESTful 하지 않은 게 되겠죠...!! 조건은 구글에도 많이 나와있지만, "당신의 서비스가 RESTful 하지 않은 이유" 라는 글이 알기 쉽게 잘 정리되어있어서 가져왔습니다.

 

https://beyondj2ee.wordpress.com/2013/03/21/%EB%8B%B9%EC%8B%A0%EC%9D%98-api%EA%B0%80-restful-%ED%95%98%EC%A7%80-%EC%95%8A%EC%9D%80-5%EA%B0%80%EC%A7%80-%EC%A6%9D%EA%B1%B0/

당신의 API가 Restful 하지 않은 5가지 증거

아래는 SOAP와 REST API를 비교 한 Stack Overflow의 답변인데요, 잘 와닿기도하고 재미있어서 가져왔습니다