What is "API"?
온라인 상에서 우리는 다양한 형태의 api를 통해 정보를 주고 받는다.
이때 웹개발에 있어서 api라고 한다면 WebAPI를 가르키는 것이 일반적이다.
WebAPI의 종류에도 다양한 것들이 있는데, 그저 우리가 원하는 데이터를 가져오기 위해 HTTP reqeust를 보내면 순수한 데이터의 형태로 값을 주는 형태가 있는가 하면, 카카오톡이나 인스타에 자동응답을 할 수 있게 하는 API 등이 있다.
사용자가 서버로 '요청'을 하면, 서버는 사용자의 요청을 받아 내부적인 함수를 호출하여 결과값을 처리하고 이를 '응답'으로 반환한다. API의 작동 방식에는 여러가지가 있는데, Rest API 방식이 가장 많이 사용되고, 실시간 기능을 위해서는 Websocket API 방식도 사용된다.
Then, what the fuck is "REST API" ? (feat. SOAP API)
그럼 그 망할 REST API란 무엇일까? 사실 REST API라는 것이 따로 존재한다기 보다는, 하나의 방법론에 가깝다. REST(Representational State Transfer)라는, 즉 자원을 이름으로 구분하여 해당 자원의 상태 정보를 응답으로 받는 형식을 의미한다.
자원은 응답자가 가지고 있는 데이터(텍스트, 이미지, 소프트웨어 그 자체)를 의미하며 이를 명확한 이름으로(ex 학생에 대한 정보면 students) 구분하여 통신을 주고받는 것을 의미한다.
구체적인 정의는 "HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것"이다.
위에서 얘기했듯이, 이름으로 명시된 자원에 대해 HTTP 요청을 보낼 여러 동사들을 이용해 CRUD(생성,수정,업데이트,삭제)를 수행하는 것이라고 이해하면 편할 것 같다. 그리고 '경량화'가 큰 장점인데, 애초에 목적이 데이터만을 수신하는 것이기 때문이라고 생각한다.
(대부분 JSON 형태로 데이터를 주고 받지만, HEADER에 application 포맷을 달리 설정해서 HTML FILE을 받아올 수도 있다. 하지만 이것은 응답자 측에서 받아오게 만들어야만 한다)
이와 반대되는 내용이라고 할 것이 SOAP API인데, REST API는 하나의 프로토콜이 아닌 그 방법론을 뜻하는 "아키텍쳐 스타일"이라고 한다면, SOAP API는 그 자체로서 하나의 프로토콜이다. 보안을 위해 HEADER에 많은 정보를 담아야 하고, 응답으로 기능 위주의 구조화된 정보를 받아오기에 REST API보다는 무거운 편이다. JS에서 SOAP API를 구현하는 방법은 AJAX를 활용하는데, 이때 사용하는 것이 XMLHTTPRequest이다. 데이터 포맷이 XML이 주가 되며, XML일 경우엔 이후 JSON.parse()를 통해 json의 형태로 다시 불러와야 한다. 그렇다고 구시대의 유물로 없어져야 할 것은 아니다. 확실히 보안적인 절차가 정해져 있는 프로토콜이다 보니, REST API보다 보안성은 높다. 그래서 일반적인 웹서비스보다는 기업 서비스에서 쓰일 수는 있다.
Ok then. But, what on earth is the "RESTful"?
Restful은, "REST 하다"는 뜻이다. 그니까, REST API 형식에 맞춰서 쓰여졌느냐? 이것이 RESTful 한가 아닌가로 얘기가 되어지는 것이다. 즉, REST API는 하나의 아키텍쳐 스타일이기 때문에 어떻게 만들든 상관이 없다. 하지만 REST API에 맞는 형식으로 만들어주면 요청자와 응답자가 더욱 효율적으로 통신할 수 있기 때문에 어떻게 RESTful 한 데이터를 만드느냐는 얘기가 튀어나오게 되는 것이다.
How to make my API "RESTful"?
- 슬래시 구분자(/ )는 계층 관계를 나타내는데 사용한다.
Ex) http://restapi.example.com/houses/apartments-
URI 마지막 문자로 슬래시(/ )를 포함하지 않는다.
-
URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI이 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 한다.
-
REST API는 분명한 URI를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않는다.
Ex) http://restapi.example.com/houses/apartments/ (X)-
하이픈(- )은 URI 가독성을 높이는데 사용한다. 불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높인다.
밑줄(_ )은 URI에 사용하지 않는다. 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용하지 않는다. -
URI 경로에는 소문자가 적합하다.
URI 경로에 대문자 사용은 피하도록 한다.
RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문이다. -
파일확장자는 URI에 포함하지 않는다.
REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다. -
Accept header를 사용한다.
Ex) http://restapi.example.com/members/soccer/345/photo.jpg (X)Ex) GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg (O)- 리소스 간에는 연관 관계가 있는 경우
/리소스명/리소스 ID/관계가 있는 다른 리소스명
Ex) GET : /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)
출처 (https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html)
Hey, let me know about the "WebSocket API"!
나도 구현해보지 않은 거라 잘 모르지만... MDN의 정의를 따오자면
웹 소켓은 사용자의 브라우저와 서버 사이의 인터액티브 통신 세션을 설정할 수 있게 하는 고급 기술입니다. 개발자는 웹 소켓 API를 통해 서버로 메시지를 보내고 서버의 응답을 위해 서버를 폴링하지 않고도 이벤트 중심 응답을 받는 것이 가능합니다.
서버를 폴링한다는 것은, 실시간 서비스를 만들기 위해 주기적으로 정보가 있던 없던 간에 요청을 하여서 사용자는 본인이 요청하지 않았음에도 응답을 받는다. 이렇게 되면 리소스를 낭비하는 일이 잦아지고, 정보가 없는 경우엔 오버헤드가 발생하게 된다.
(오버헤드 : 어떤 처리를 하기 위해 들어가는 간접적인 처리 시간 · 메모리 등을 말한다. 즉, 원래 처리하기 위한 시간에 더해서 간접적인 이유로 시간이 더 지연된다면, 그 추가분이 오버헤드이다.)
이런 서버 폴링으로 인한 단점 없이 이용할 수 있는 통신 방식이 WebSocktet API이다.
