#10. HTTP Method Anatomy

제목에서 보이는 바와 같이 난 단지 HTTP Method 혹은 HTTP Verb라고 부르는 것들을 정리할 필요성을 느끼게 되어서 이 글을 쓰게 되었다. 간단한 게 각 메서드가 무엇인지 정리하려고 생각했지만 찾아볼수록 모르는 것들이 쏟아져 너무 방대하게는 하기에 글 쓰는 목적성이 떨어질 것 같고 개인적인 시간 제약도 있기에 그 안에서 최대한 정리를 해보려고 한다.  

 

정리해볼 내용으로는 제목과 같이 저 메서드들이 무엇이며 원리가 무엇인지 알아볼 것이다. 

이에 앞서서 CRUD와 REST API란 개념도 집고 넘어가 볼 내용이 있어 평소보다 길이가 있다.

그러므로, 시작하기에 앞서 스트레칭하거나 커피나 물 한 잔 마시고 나서 읽어보는 것도 좋을 거 같다.

 

---

 

 

 

먼저, CRUD란 용어에 대해 살펴보고 가야한다. 

In computer programming, create, read, update, and delete (CRUD) are the four basic functions of persistent storage.

출처: 위키피디아

 

 

위키피아에서 가져온 내용을 보자.

컴퓨터 프로그래밍 용어로 create, read, update, and delete는 persistent storage(영구 저장소;  PS) 함수의 머리글자를 따 만든 것을 알 수 있다.  데이터를 만들고, 읽고, 수정

하고, 지울 수 있는 4가지 함수를 지칭하는 것이다.

 

 

그렇다면 PS란 무엇일까? 

Persistent storage is any data storage device that retains data after power to 
that device is shut off. It is also sometimes referred to as nonvolatile storage.

출처: NetApp

 

 

=> PS는 어떤 장비의 정원이 꺼진 후에도 데이터가 남아있는 그 어떤 데이터 저장소 장치 또는 휘발성이 없는 저장소라고 부르기도 한다. 

 

 

그렇다면 PS가 왜 필요한걸까?

Because persistent storage is designed to survive independently of any running instance, it can be used for any data that needs to be reused.

출처: NetApp

=> PS는 데이터의 재사용성을 위해 만들어졌기 때문이다. 

 

 

정리하면, 

CRUD라는 용어는 데이터를 만들고 읽고 수정하고 삭제하고자 만든 메서드(함수)이며

이것들은 컴퓨터 장치 중 데이터들의 재사용성을 목적을 가진 장치

즉, 데이터를 영구적으로 보관할 수 있는 저장소에 있는 메서드(함수)를 지칭한다는 것을 알 수 있다.

 

 

---

 

 

여기서 한 가지 개념을 더 살펴보자!

 

REST API란 용어를 들어봤는가?

 

API를 공부하다 보면 무조건 한 번쯤 마주치는 용어다.  

먼저, API란?

서버 자원을 잘 가져다 쓸 수 있게 만들어 놓은 수단이다. 이 API에 지정된 형식으로 서버에 요청과 명령 같은 것들을 할 수 있다.

"스타벅스 메뉴판"을 예로 들 수 있다.  우리가 아이스 아메리카노를 앱에서 주문하기를 눌렀을 때 지정된 형식에 의해 주문 내용이 서버로 전송이 된다. 감이 오는가? 

 

이전에 정리한 내용이 있으니 참고해도 좋을 거 같다. 링크

 

 

REST란?

On the other hand, Representational State Transfer — or REST — is a popular architectural style for software, especially web APIs. It’s defined by five design constraints that, when followed, produce an application with specific properties, including performance, simplicity, and reliability.

출처: nordicapis

 

 

Representational state transfer (REST) is a de-facto standard for a software architecture for interactive applications that typically use multiple Web services. In order to be used in a REST-based application, a Web Service needs to meet certain constraints; such a Web Service is called RESTful.

출처:위키피디아

 

 

=> Representational State Transfer의 약자이며 소프트웨어 세계에서 유명한 아키텍처 스타일이라고 한다. 특히 web API로서 유명하다고 한다. 일반적으로 여러 웹서비스를 사용하는 Interactive Application의 소프트웨어 아키텍처에 대한 표준이라고 한다. 이 표준은 아래 원칙들을 가리키며 이 원칙들을 만족하는 웹 서비스들 우리는 RESTful 하다고 한다. RESTful 한  API는 요청을 보내는 주소(URL)만으로 대략적으로 무엇을 요청하는지 알 수 있다. 

 

 

URL Structure from Wikipedia

출처: 위키피디아

 

예를 들면,

Client(혹은 user)가 Server에 특정 요청을 했다.

1) www.google.com에서 www.google.com/mailbox,  
2) www.google.com/mailbox에서 www.google.com/mailbox/1  

1)은 구글에 있는 유저가 구글 메일함에 가고자 요청을 보냈을 때 주소(URL)다. 

2)는 구글 메일함에 있는 유저가 첫 번째 메일을 보고자 눌렀을 때 서버로 보내는 주소(URL)다.

 

 

5가지 원칙은 아래와 같다.

1. Client-Server: The client and server act independently.
2. Stateless: The server does not record the state of the client.
3. Cacheable: The server marks whether data is cacheable.
4. Uniform Interface: The client and server interact in a uniform and predictable way. 
5. Layered System: The application behaves the same regardless of any intermediaries between the client and server.

출처: nordicapis

1. 클라이언트와 서버는 독립적이어야 한다.
2. 서버는 클라이언트의 상태(state)에 대한 기록을 하지 않는다.
3. 서버는 데이터를 캐싱할 수 있어야 한다.
4. 클라이언트와 서버는 예측 가능하며 통일된 방식으로 상호작용한다. 
5. 애플리케이션은 클라이언트와 서버 사이에 어떤 중계자(중계하는 것)에 상관없이 동일하게 작동합니다.

 

위에 설명한 REST API에 대한 예시처럼 메일함에서 첫 번째 메일을 보려고 누르는 동작은

서버에게 첫 번째 메일을 보고 싶다고 요청하는 동작이며 동작의 목적은 메일을 '읽기' 위해서 라고 충분히 생각할 수 있을 것이다.

그렇듯, 우리가 읽기뿐만 아니라 메일을 만들고, 읽고, 수정하고, 삭제하고 이런 동작을 할 수 있을 것이다. 

 

 

흠.. 어디서 많이 들어본 거 같은데..?라고 생각이 들면 땡큐고 아니어도 괜찮다.

바로 이 글의 초반부 CRUD에 대한 설명이다. :)

 

 

계속 흐름을 이어가 보자.

서버에 API 요청을 보낼 때는 HTTP라는 프로토콜(규약)을 이용해 신호를 전송하는데  HTTP 요청에도 여러 가지 메서드가 존재한다. GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH 메서드가 존재하는데 REST API에서는 이중 GET, POST, DELETE, PUT 혹은 GET, POST, DELETE, PUT, PATCH를 사용한다.

 

 

간단히 설명하면,

1) GET은 정보를 받아오고 DELETE는 정보를 삭제한다.

2) POST는 새로운 정보를 추가할 경우, PUT은 특정 정보를 변경할 때, PATCH는 원하는 정보만 변경할 경우

사용한다. 

2) 메서드에는 관련 정보를 BODY 부분에 담아 임무를 수행한다.

참고: MDN

 

 

이렇듯 각 메서드마다 정해진 행동이 존재한다. 하지만 이런 메서드들이 정해진 행동만 할 수 있는 것은 아니다. 

예를 들어, POST 메서드 하나만으로도 데이터를 읽고 쓰고 수정하고 지우고까지 다 해 먹을 수 있다. 그렇다면 만약 POST만으로 모든 처리를 한다면 어떨까..? 매우 매우 매우 혼란스러울 것이다... 끔찍하다. 상상해보자!

 

하지만, 우리에게 REST API가 있다.

이렇듯, REST API는 HTTP 요청을 보낼 때 어떤 URL에 어떤 메서드를 사용할지 개발자들 사이에 널리 지켜지는 약속이며 이를 통해 우리가 코드를 보면서 코드의 내용 또한 유추할 수 있는 것이다.

 

총정리(요약)를 해보면 

클라이언트와 서버 간의 요청에 필요한 API가 존재하며 이 API를 사용할 때 지켜야 할 약속을 REST API라고 할 수 있다.  API 요청할 때에 HTTP 프로토콜을 이용하게 되는데 이 프로토콜에는 CRUD와 같이 생성, 조회, 갱신, 삭제와 같은 맥락의 메서드들이 존재하며 그 메서드들은 REST API에서 지정한 규칙에 부합하도록 사용한다.

 

 

 

출처: https://shareurcodes.com/

 

 

 

마치는 말

지금까지 글을 보면서 완벽하게 이해가 안 되어서 힘들 수도 있다. (괜찮다. 글쓴이도 정리하면서 공부가 더 필요하다고 느낀다!)

하지만, 우린 이 글에서 하고자 하는 것은 Method들에 대해 알려고 하는 것이기 때문에 저런 것도 있다는 것만 알아도 괜찮으니 일단 넘어가자. 못 넘어가겠으면 다시 글을 읽어 보거나 이 글이 아니어도 검색을 통해 지속적으로 공부하다 보면 조금씩 이해가 될 것이다!

영상으로 보는 게 편한 경우에 얄팍한 코딩 사전을 시청해보자. 글쓴이도 이 글을 정리하면서 일부분 참고하였고 정리를 참 깔끔하게 잘한다. 맛집이다.! ㅎ