client . client는 일반적으로 WEB에 연결된 장치를 의미한다. . 모바일 장치, pc, web browser 등이 client 에 속한다.
server . 일반적으로 web page, site을 저장하거나 application 을 구동하는 장비를 server라고 지칭한다.
web page 접속 시 발생하는 일들. . 브라우저는 DNS에 입력받은 URL 주소를 요청 후 실제 IP를 확인. . 브라우저는 server 로부터 web site의 사본을 HTTP을 사용하여 요청한다. . server는 요청을 수신 후 응답코드와 함께 응답 메세지를 브라우저에 전달한다. -> TCP 소켓을 통한 응답이기때문에 Strem 형식으로 전달 및 수신된다. . 브라우저는 응답을 수신 후(해당 stream을 모두 수신 및 조립 완료 후) web page로 유저에게 노출한다. -> 일반적인 경우에 html 이 포함된 응답이 전달되므로 이렇게 설명함.
인터넷은 어떻게 동작하는가? 두개의 컴퓨터 사이에서 통신이 필요한 경우 우리는ㄴ 다른 컴퓨터와 물리적, 혹은 무선으로 연결되어야 한다. 이런 네트워크 연결은 단순히 두대의 컴퓨터로 제한되진 않는데 연결 수가 많아질수록 매우 복잡해진다. (네트워크 연결 구조에 대해서는 나중에 포스팅 할 예정이다.) 이러한 복잡한 연결을 줄이기 위해서 각 PC는 "라우터"라는 장비에 연결되며, 이 라우터는 신호에 따라서 특정 PC에 메세지를 보내고 잘 도착하는지를 확인한다. 이러한 방식으로 특정 라우터에 소속된 pc 집단에서의 통신 또는 다른 라우터에 속한 pc집단 사이에 통신을 할 시 두대의 라우터 사이의 연결만으로도 통신이 가능해진다.
이러한 방식으로 네트워크를 확대하는 것이 가능하며 같은 네트워크에 속한 pc같의 통신이 가능해진다. 여기서 더 나아가 라우터로 직접 연결되지 않은 다른 네트워크에 "모뎀"을 통해 접근하며 다른 지역의 네트워크까지 통신이 가능해진다. 이러한 서비스를 제공하는 인터넷 서비스 제공 업체를 우리는 ISP(Internet Service provider)라고 부른다.
IP Address란? 그렇다면 네트워크 상에서 다른 PC에 대해서 어떠한 방식으로 특정을 하는 방법이 필요하다. 현재 우리의 인터넷 환경은 IP주소를 통해 특정 라우터 혹은 PC를 구분하는 방식을 사용한다. IP주소 할당 방식 등 좀더 깊은 내용이 있지만 해당 포스팅에서는 다루지 않는다.
DNS 하지만 오늘날 우리는 naver등에 접속할 때 위의 IP 주소를 직접 URL창에 입력하지 않는다. 우리가 입력하는 것은 "domain"인데 이는 Domain Name Service를 통해 IP 주소와 mapping 되어 있기 때문에 어떠한 네트워크에 접속할지를 판단할 수 있다. (DNS 역시 별도 포스팅을 통해 알아보자.)
restful api란 무엇인가? restful api란 두 컴퓨터 사이의 정보를 안전하게 교환하기 위해 사용되는 인터페이스 중 하나이다. 여러 API 방식 중 일반적으로 REST 원칙을 따르는 API를 지칭한다.
대부분의 사람들이 REST API는 URL 을 통해서 Resource를 식별하고 Http Method를 사용하여 해당 Resource에 대한 행위를 규정하며 그 결과를 전달 받는 것으로 알고있다 이 포스팅에서는 REST API에 대해서 좀더 자세히 알아본다.
REST란? ( Representational State Transfer ) 분산 하이퍼 미디어 시스템을 위한 API 아키텍쳐 스타일을 의미한다. 오늘날 HTTP 규약만 잘 지켜도 REST API 조건 중 다수를 만족할 수 있다. 그렇다면 REST API 아키텍처 스타일에는 어떤것들이 있을까? 주요 스타일은 아래의 6가지가 존재하며 해당 사항에 대해 좀더 자세히 알아볼 것이다. . client - server . stateless . cache . uniform interface . layered system . code on demand(Optional)
Client - Server . UI는 client에서, data는 server에서 처리하여 관리한다. . 즉, client와 server가 별도로 개선될 수 있어야 한다.
Stateless . client와 server는 요청을 완료할 때 필요한 모든 정보를 제공해야 한다. . 요청이 일어난 시점에 제공된 정보만을 사용하여 작업을 완료할 수 있어야 함.
Cache . 응답은 cache될 수 있어야 하며, 이는 성능향상에 도움이 된다.
Layered System . 계층화된 구조를 활용하여 각 Component의 행동을 제약하고 추상화 할 수 있어야 한다. -> REST Server는 다중 계층으로 구성될 수 있고 보안, 로드 밸런싱, 암호화 계층 등 을 추가할 수 있다.
Uniform Interface : resource에 대한 조작을 통일되고 한정적인 interface로 수행하는 아키텍처를 의미한다. . resource는 uri로 식별이 되어야 한다. . resource에 대한 관리는 http method에 해당 방식이 포함되어야 한다. -> http method로 CRUD 구분 . self-descriptive message -> message는 스스로를 설명해야한다 -> message 안에 해당 요청, 응답에 대한 모든 정보가 포함되어야 한다. => ex : message 안에 Content-Type이 생략되어 있는 등의 경우는 self-descriptive message를 불만족. . HATEOAS -> application의 상태는 항상 hyperlink를 이용해서 전이되어야 한다. => ex : 게시글 생성 버튼 링크를 통해 application의 상태가 변경된다.
Code on Demand(Optional) . Server에서 보낸 정보를 토대로 client에서 code를 실행할 수 있어야 한다. -> ex : server 가 client 에 응답으로 보낸 것중 javascript
Uniform Interface가 필요한 이유 . server와 client 간의 독립성을 보장하기 위해서 -> ex : server가 기능을 변경해도 client는 업데이트 할 필요가 없다. -> ex : web의 경우 브라우저 업데이트가 되어도 web site는 변경할 필요가 없다.
REST API를 구현 시 주의해야 할 설계 원칙은 어떤 것들이 있을까 . Url 은 Resource를 표현해야 한다. . Resource에 대한 행위는 Http Method를 통해 나타낸다. . 슬래시는 Url 마지막에 사용하지 않는다. . 하이픈은 Url 가독성을 높이기 위해서 사용할 수 있다. . 언더바는 띄어쓰기처럼 보일때가 있고, Url에 혼동을 줄 수 있어 사용하지 않는다. -> 하이픈을 사용하는걸 추천 . Url 경로에는 소문자만 사용한다. -> Url은 대소문자를 구분하기 때문에 다른 resource로 인식할 여지가 있다. . file 확장자는 url에 포함시키지 않는다. -> 대신 Header에 AcceptHeader를 사용하여 file의 확장자를 알수 있게 한다.
REST API를 통한 CRUD 작업과 이에 대응하는 Http Method . CREATE : POST . READ : GET . UPDATE : PUT, PATCH . DELETE : DELETE => Http method와 관련된 CRUD에 대해서는 추후 좀 더 자세한 포스팅으로 다룰 예정이다.
