REST API에 대해 알아보자

시작하기 전에

해당 블로그에 작성되는 글은 주인장의 지극히 주관적인 생각이 다수이며, 대부분의 지식은 구글링을 통해 얻고 있기 때문에 옳지않은 정보가 있습니다. 

잘못된 부분이나 수정해야 하는 부분이 있다면 과감히 덧글을 남겨주세요! 모르는게 많은 새싹입니다

REST API란?

1. HTTP를 통해 SOAP나 쿠키를 통한 세션 트래킹같은 별도의 전송계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다.(프로토콜이 아니다)

2. 기존의 Web application이 Service 중심이었다면  Rest는 Resource중심이다.

3. Resource  중심으로 설계하며 CRUD에 해당하는 HTTP의 4가지 메소드( POST, GET, PUT, DELETE)를 이용한다.



*SOAP(simple Object Access Protocol) : 일반적으로 알려진 HTTP, HTTPS, SMTP등을 통해 XML기반의 메시지(Header & Body)를 컴퓨터 네트워크 상에서 교환하는 프로토콜이다. 보통의 경우 원격 프로시저 호출(Remote Procedure Call:RPC)패턴으로 클라이언트 - 서버로 메시지를 요청하며 요청에 대해 서버는 즉시 응답한다. 

REST의 구성 요소

1. Resource : 자원에 대한 정의이다. HTTP URI 형태로 나타난다.

2. Verb : 자원에 대한 행위이다. HTTP Method ( REST에서는 CRUD에 대한 동작을 나타낸다. POST, GET, PUT, DELETE이 해당된다.)

3. Representation : 자원의 행위에 대한 내용이다. HTTP Message Payload를 나타낸다.

REST의 특징(?)을 알아보자.

1. 클라이언트 / 서버 구조

- 서버가 클라이언트의 정보로 부터 조금은 자유로워지는 구조이다. 클라이언트가 서버로 전송하는 데이터에 대한 의존성을 낮춰준다.


2. 무상태성(Stateless)

- 각 요청에 대한 컨텍스트가 서버에 저장되어서는 안된다. REST는 Resource 중심이기 때문에 서버는 API를  통해 동작을 이해 하고 Resource에 접근할 수  있다. API를 작성하는 방법에 대해서는 아래에서 다룰 것이다.    Client는 서버에게 자신을 표현(?) 할 수있는 별도의 정보를 전달해야 한다.(API key or Token 정보)


도움이 될 것 같은 이미지를 구해왔습니다*^^*

3. 캐시 처리 가능(Cacheable)

- www에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다.
캐싱처리가 잘되면 클리이언트 - 서버 간   상호작용을 부분적, 완전하게 제거하여 scalability와 성능을 향상시킨다.


4. 계층화(Layered System)

- 클라이언트는 보통 대상 서버에 직접 연결되어쓴지, 중간 서버를 통해 연결되었는지를 알 수 없다.
중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 규모 확장성을 향상시키는데 유용하다.


5. Code on demand

- Server 측에서 실행가능한 코드를 Client에게 전송해줌으로서, Client의 기능을 확장할 수 있다.


6. 자체 표현 구조(SELF-DESCRIPTIVNESS)

- 별도의 문서가 필요없다 왜냐면! API를 보고 다 알수있기 때문이다

RESTful이 되기 위해서

1. 동사형 보다는 명사형을 추구하라. (행동의 정의하는데 명사를 왜 사용하는지 모르겠다..알려주실분!)

- ex) /getCompany/mocam (x)

2.명사의 단수형 보다는 복수형을 추구하라.

- ex) /companies/mocam (o)

3. URL의 Depth는 level2 정도를 지향하라고 한다. 

- URL을 간단하고 직관적으로!

- API를 보고 동작을 이해할 수 있게 작성

- ex) /companies/mocam  <= 사실 작성자 말고(명사형이라 더 힘들다)는 이해하기 힘들꺼 같다.

- 서브 URL을 이용하는 방법  <= 이부분에 대해서는 잘 모르겠으니 여기를 참고하세요


4. HTTP 응답코드

- 사실 각 유명한 회사마다 사용하는 응답코드에는 차이가 조금씩 있다고 합니다.

- 권장하는 기본 Response Code 입니다.


(1) 200 : Success


(2) 400 : Bad-request


(3) 401 : 인증 인가 실패


(4) 404 : Resource not Found - 리소스 찾을 수 없음

(
5) 500 : Internal Error


5. HTTP Response Body 

- 에러처리에 관한 상세한 내용은 HTTP body를 통해 표현합니다.

- 각 숫자 대역마다 Error Code의 범위를 미리 정해 놓습니다.

- ex) 회원관련 에러 1000대, 상품관련 에러 2000대)

6. 부분 응답(partial Response)

- 이 부분도 추가적인 공부가 필요하다.. 잘 모르겠다ㅜ.ㅜ

- 검색 HTTP GET에 쿼리스트링을 이용한다.

- ex) user/?name=dongsu&region=seoul&offest=20&limit=10


- HATEOS(HyperMedia as the Engine of application state) 하이퍼미디어의 특징을 이용하여 HTTP Link를 함께 리턴하는 것이다. 

예를 들어 페이징처리 외에도 자바스크립트 소스나, 이후 발생할 url 링크등을 함께 투척하는 경우를 말한다.

예를 들어 FaceBook의 페이징 스타일은 : /record?offset=100&limit=25 <=쿼리스트링을 통해 요청을 보낸다.

급하게 포스팅을 공유해야되서 설명이 많이 뒤죽박죽, 들쑥날쑥 난리도 아니네요.
얼른 바쁜일을 마치고 내용을 수정하고 보강하도록 하겠습니다.