Backend 세미나 1주차] HTTP와 REST API

HTTP 란?

HyperText Transfer Protocol로 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이다.

- 웹에서 이루어지는 모든 데이터 교환의 기초

HTTP의 특성

1. Stateless

- Stateless하기 때문에 Scaling이 자유롭다. -> 상태를 보관하지 않으므로 어떤 서버가 응답해도 상관 없음 (클라이언트의 요청이 대폭 증가하게 되더라도 서버를 증설하는 방식을 사용할 수 있다.)

=> 서버가 상태를 알아야 할 때 Ex) Login기능 구현 -> 브라우저 쿠키나 서버 세션, 토큰 등을 사용해 상태를 유지해야 한다.

• Stateful : 서버와 클라이언트 간 세션의 상태에 기반해 클라이언트에 응답을 보내므로 세션 상태를 포함한 클라이언트와의 세션 정보를 서버에 저장한다. 즉, 세션 상태에 의존적 Ex) TCP
• Stateless : 클라이언트의 요청에 대한 응답만을 보내 클라이언트와의 세션 정보를 기억할 필요가 없으므로 해당 정보를 서버에 저장하지 않는다. 즉, 세션 상태와 독립적 Ex) HTTP, UDP

2. Connectionless

- 클라이언트와 서버가 한 번 연결을 맺은 후에 클라이언트 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어버리는 성질 (http는 불특정 다수와 통신하도록 설계되어 있다.)

- 하지만 클라이언트를 기억하고 있지 않기 때문에 같은 클라이언트와 계속 통신할 때도 매번 새로운 연결을 시도해야 해서 트래픽이 많고 큰 규모의 서비스를 운영할 때 한계를 보인다.

=> KeepAlive (지정된 시간 동안 서버와 클라이언트 사이에서 패킷 교환이 없을 경우 상대방의 상태를 묻는 패킷을 주기적으로 보내는 방식 -> overhead 발생할 수 있음)

HTTPS 란?

- https: http에 secure, 즉 보안성을 추가한 프로토콜

- SSL 인증서(Secure Sockets Layer)사용 -> 서버에서 클라이언트로 전송되는 정보가 암호화 되기 때문에 데이터를 가로채더라도 쉽게 해독할 수 없다.

- 데이터 무결성 제공

- S.E.O -> 검색 엔진 최적화에 유리하다.

URI / URL / URN

인터넷 자원을 나타내는 용어들

URI (Uniform Resource Identifier)

- 인터넷 자원을 나타내는 고유 식별자

- 인터넷에 있는 자료의 id 역할을 하기 때문에 유일해야 한다.

- URL의 상위 개념

URL (Uniform Resource Locator)

- 컴퓨터 네트워크 상에서 리소스가 어디 있는지 알려주기 위한 규약 (자원의 실제 위치)

- http, https 같은 프로토콜을 포함한다.

 

=> 즉, 인터넷 자원의 위치를 나타내는 경우 uri, url 모두 해당하지만 식별자(path variable, query parameter)를 사용해 특정 자원을 식별하려 하는 경우는 uri만 해당한다.

URN (Uniform Resource Naem)

- 자원의 이름을 나타낸다.

- page 이후 부분까지 포함하며 프로토콜은 포함하지 않는다.

자원 식별 방식

1. Path variable

 Ex) /user/1

      /user/2

      /user/3

2. Query Parameter

 Ex) /user?id=1

      /user?id=1&age=10

REST API (REpresentational State Transfer 형식의 API) 

클라이언트의 종류가 웹브라우저, ios앱, android앱 등 다양해지면서 이러한 클라이언트들에게 정보를 제공하는 방식을 1개로 일원화시키고 싶어졌다. -> 대표적인 방식이 http 프로토콜로 api를 제공하는 것, 이러한 api를 rest api라고 한다.

 

API 란?

- 응용 프로그램에서 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스

Ex) 날씨 api, 소셜로그인 api

 

REST API 란? 

- 웹상에서 사용되는 여러 리소스를 http uri로 표현하고 해당 리소스에 대한 행위를 http method로 정의한다.

- 쉽게 말해, http uri로 정의된 리소스를 어떻게 할 지 구조적으로 깔끔하게 표현하는 방법이다.

- http 프로토콜을 그대로 사용하기 때문에 http의 특성과 비슷한 특성을 가지고 있다.

1. Client-Server 구조
2. Stateless
3. Cacheable - cache를 사용해서 대량의 요청을 효율적으로 처리할 수 있다.
4. 계층형 구조 - 다중 계층으로 구성될 수 있어 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 프록시, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 된다.
5. Code On Demand (선택)
6. Uniform (유니폼 인터페이스) - URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일

REST API의 구성

1. 자원 - URI  //클라이언트가 URI를 이용하여 자원을 지정하고 해당 자원에 대한 조작을 서버에 요청한다.
2. 행위 - HTTP 프로토콜의 METHOD를 사용한다.  //get, post, put, delete 메소드 제공해 crud 기능을 구현할 수 있다.
3. 표현 - 클라이언트가 자원의 상태에 대한 조작을 요청했을 때 서버가 이에 적절한 응답을 보낸다.  //json, xml 등을 통해 데이터를 주고 받는다.

HTTP METHOD의 주요 메소드

• GET : 리소스 조회 (READ)
  • GET /members/100
• POST : 요청된 자원을 생성 (CREATE)
  • 요청 시 Body값과 Content-Type 값을 작성해 서버로 요청 데이터를 전달한다. (Body값에 주로 json형태로 들어가게 된다.)
  • POST /members
    body : {"username" : "kim"}
    Content-Type : "application/json"
• PUT : 요청된 자원을 전체 수정 (UPDATE)
  • 리소스가 기존에 없으면 새로 생성한다.
  • 클라이언트가 리소스가 무엇인지를 알고 URI를 지정해야 한다. (POST와의 차이점)
  • PUT /members/100
    body : {"username" : "gomrye"}
    Content-Type : "application/json"
  • 완전히 덮어 씌어 버리는 개념이기 때문에 기존에 있던 내용이 남아있지 않게 된다.
• PATCH : 요청된 자원의 일부를 교체해 수정 (UPDATE)
  • body에 {"age" : 50} 값만 보내도 기존에 있던 username 필드가 사라지지 않고 age만 50으로 변경된다.
• DELETE : 요청된 자원을 삭제 (DELETE)

REST API URI 설계 규칙

1. URI는 정보의 자원을 표현해야 한다. - 리소스명은 동사보다는 명사를 사용한다.
2. 자원에 대한 행위는 HTTP METHOD로 표현한다. Ex) POST /members/save -> X, POST /members -> O

(여기서 부터는 세부 규칙)

1. 슬래시 구분자는 계층 관계를 나타낼 때 사용하고 마지막에는 슬래시를 붙이지 않는다. for 통신에 혼동 방지
2. URI 가독성을 높이기 위해 하이픈(-)을 사용한다.  //_는 밑줄에 가려져 안 보일 수 있으므로 사용하지 않는다.
   Ex) http://rest-api.example.com -> O
        http://rest_api.example.com -> X
3. URI 경로에는 소문자가 적합하다.
4. 파일 확장자는 URI에 포함하지 않는다. (대신 Accept header를 사용한다.)
   http://restapi/example.com/members/soccer/345/photo.jpg -> X
   GET /members/soccer/345/photo
   HTTP/1.1 Host: restapi.example.com Accept:image/jpg -> O
5. 리로스 간에 연관관계가 있는 경우 /리소스명/{리소스ID}/관계있는 다른 리소스명의 형식을 따른다.
   GET :/users/1/devices -> 1번의 user가 갖고 있는 device를 가지고 오라!

HTTP status code

서버로 보낸 요청 상태를 나타내는 코드, 서버로 보낼 작업의 수행 상태를 알려줄 수 있도록 표준에 맞춘 일종의 약속이다.

- 에러의 종류에 대해 커뮤니케이션하기 편리하다.

- http요청이 잘 이루어졌는지 확인하기 좋다.

• 1xx (Informational) 요청이 수신되어 처리 중, 프로세스를 계속한다.
• 2xx (Successful) 요청을 성공적으로 받아 처리했다.
  
• 3xx (Redirection) 요청을 완료하려면 추가 행동이 필요하다.
• 4xx (Client Error) 잘못된 문법 등으로 서버가 요청을 수행할 수 없다.
• 5xx (Server Error) 서버가 유효한 요청을 처리하는데 실패했다.
  503 -> 서버 터졌을 때 나오는 코드

API 명세서 작성 실습

Postman을 사용해 실습했다.
- Body의 raw를 사용해서 json형태로 데이터를 주로 보낸다.

- id 6번인 data delete 했는데 또 delete 요청 -> No such User 메세지 나오고 404 Not Found status가 나온다.