보통 서버 개발자, 백엔드 개발자 둘중 하나로 부른다.
하나의 프로젝트에서 프론트엔드-백엔드, 안드로이드-서버, iOS-서버 이런 식으로 붙이기 나름이라고 생각한다.
좀 찾아보고 내가 이해한 바는 이렇다.
- 서버 개발자 : 서버에서 돌아가는 프로그램 개발
e.g. 서버 간의 통신을 위한 프로그램, 분산처리를 위한 프로그램, 게임 서버 프로그래밍, 클라이언트가 볼 수 없는 뒤에서 작동하는 "서버"에서 돌아가는 프로그램을 개발 - 백엔드 개발자 : 보통 웹 개발 분야에서 프론트엔드 개발의 반대 개념
따지고 보면 웹에만 국한된 개념이 백엔드 개발, 서버를 이용하는 모든 프로그램에 해당하는 개념이 서버 개발인 것 같다.
내가 독학하고자 하는 건 HTTP 기반의 API 서버를 만드는 것 이다.
1. HTTP(Hyper Text Transfer Protocol)
네트워크 장치 간에 정보를 전송하도록 설계된 애플리케이션 계층 프로토콜
일반적인 흐름에 클라이언트 시스템에서 서버에 요청한 다음 서버에서 응답 메시지를 보내는 작업이 포함됨.
프로토콜이란?
컴퓨터 내부에서, 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙 체계. 컴퓨터의 공용어와 같으며 상이한 소프트웨어 하드웨어가 네트워크 내에서 프로토콜을 사용해 서로 통신할 수 있도록 한다.
즉, WWW(World Wide Web)에서 통신 규약을 정함으로써 사용자들이 서로 통신하는 데에 어려움이 없도록 하는 정해진 규약이고 HTTP는 하나의 프로토콜인 것이다. 클라이언트와 서버는 이 HTTP라는 통신 규약 내에서 통신을 하는 것!
HTTP는 기본적으로 request와 response 구조로 이루어져 있으며 클라이언트와 서버의 모든 통신이 요청과 응답으로 이루어진다.
HTTP Request의 구조
HTTP Request는 Start Line, Headers, blank line, Body로 이루어진다.
Start Line
HTTP Request Message의 시작 라인으로 HTTP Method, Request target, HTTP version의 3가지 부분으로 구성된다.
GET /test.html HTTP/1.1
[HTTP Method] [Request target] [HTTP version]💭HTTP Method
: HTTP 요청이 쿼리된 서버에서 기대하는 작업을 의미
| Method | 설명 | Idempotent(멱등성) | Cacheability | Safe |
|---|---|---|---|---|
| GET | 리소스 조회 | O | O | O |
| POST | 요청 데이터 처리(데이터 등록) | X | 가능하나 구현이 쉽지 않음 | X |
| PUT | 리소스 대체(없을 시 생성. 덮어쓰기) | O | X | X |
| PATCH | 리소스의 일부만 변경 | X | 가능하나 구현이 쉽지 않음 | X |
| DELETE | 리소스 삭제 | O | X | X |
Idempotent(멱등성)은 여러 번 연산하더라도 결과가 달라지지 않는 성질을 의미한다. 이전 요청과 동일한 멱등키를 가진 요청을 받으면, 서버에서 이 요청을 중복으로 판단한 뒤 실제로 처리하지 않고 첫 요청과 같은 응답을 반환하는 방식을 말한다. 외부 요인으로 인해 중간에 리소스가 변경되는 것은 멱등에서 고려하지 않는다.Cacheability는 응답 결과 리소스를 캐시에서 사용 가능한지를 의미한다. 내 로컬에 응답 결과 리소스를 저장하고 있는 것이 캐시인데, GET, HEAD 메소드(GET 메소드의 요청과 동일한 응답이지만 응답 본문 포함 X, 요청 시에도 헤더 정보 외에는 전송X)를 캐시로 사용하고 POST, PATCH는 실제로 사용되지 않는다. 캐시를 하려면 똑같은 리소스에 대해 캐시 키가 정확히 맞아야 하는데 POST, PATCH는 본문 내용까지 캐시 키로 고려해야 해 구현이 어렵기 때문이다.Safe는 여러 번 해당 메소드를 호출해도 리소스를 변경하지 않는 것을 의미한다. 서버의 상태를 바꾸지 않으면, 즉 읽기 작업만 수행하는 메소드는 안전하다고 한다. 이 개념은 해당 리소스의 변화 여부만 고려하고 세부적인 사항은 고려하지 않는다.- 이외에도 HEAD, OPTIONS, CONNECT, TRACE 메소드가 있다.
💭Request Target
: Host(Base URL) 뒤에 어떤 경로로 HTTP Request를 보내는지에 대한 정보 표시
💭HTTP version
: version에 따라 Request message 구조나 데이터가 다를 수 있어서 명시
Header
해당 request에 대한 추가 정보를 담고 있는 부분으로 헤더는 크게 general headers, request headers, entity headers, response headers의 4가지로 이루어져 있다. Request header는 Response header를 제외한 3가지 부분으로 이루어져 있다.
💭General Header
: Request message와 Response message에 적용되는 기본적인 정보. Body에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더
- Date : 메시지가 생성된 날짜
- Transfer-Encoding : message body의 전송 코딩 형식을 지정
- Pragma : 캐시 제어. HTTP/1.0에서 쓰던 것으로 HTTP/1.1에서는 Cache-Control이 쓰인다.
- Cache-Control : 캐시를 제어할 때 사용
- Upgrade : 프로토콜 변경시 사용
- Via : 중계(프록시)서버의 이름, 버전, 호스트명
- Connection : 네트워크 접속을 유지할지 말지 제어. HTTP/1.1은 kepp-alive 로 연결 유지하는게 default 값
- Transfer-Encoding : 사용자에게 entity를 안전하게 전송하기 위해 사용하는 인코딩 형식을 지정
💭Request Header
: HTTP 요청에서 사용되지만 메시지의 컨텐츠와 관련이 없는 패치될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더
- Host: 요청하려는 서버 호스트 이름과 포트 번호
- User-agent : 클라이언트 프로그램 정보. 이 정보를 통해 서버가 클라이언트 프로그램(브라우저)에 맞는 최적의 데이터를 전송
- Referer : 바로 직전에 머물렀던 웹 링크 주소
- Accept 클라이언트가 처리 가능한 미디어 타입 종류 나열
- Accept-charset : 클라이언트가 지원가능한 문자열 인코딩 방식
- Accept-language : 클라이언트가 지원가능한 언어 나열
- Accept-encoding : 클라이언트가 해석가능한 압축 방식 지정
- If-Modified-Since : 여기에 쓰여진 시간 이후로 변경된 리소스 취득. 캐시가 만료되었을 때에만 데이터를 전송하는데 사용
- Authorization : 인증 토큰을 서버로 보낼 때 쓰이는 헤더 - Origin : 서버로 Post 요청을 보낼 때 요청이 어느 주소에서 시작되었는지 나타내는 값. 경로 정보는 포함하지 않고 서버 이름만 포함. 이 값으로 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러 발생
- Cookie : key-value로 표현된다. Set-Cookie 헤더와 함께 서버로부터 이전에 전송됐던 저장된 HTTP 쿠키를 포함함.
💭Entity Header
: 콘텐츠 길이나 MIME 타입과 같이 Entity body에 대한 자세한 정보를 포함하는 헤더
- Content-type : 리소스의 media type 명시 ex) application/json, text/html
- Content-Length : 바이트 단위를 가지는 개체 본문의 크기
- Content-language : 본문을 이해하는데 가장 적절한 언어
- Content-location : 반환된 데이터 개체의 실제 위치 ex) /index.html
- Content-disposition : 응답 메세지를 브라우저가 어떻게 처리할지. 주로 다운로드에 사용
- Content-Security-Policy : 다른 외부 파일을 불러오는 경우 차단할 리소스와 불러올 리소스 명시
e.g. default-src https -> https로만 파일을 가져옴
e.g. default-src 'self' -> 자기 도메인에서만 가져옴
e.g. default-src 'none' -> 외부파일은 가져올 수 없음 - Content-Encoding : 본문의 리소스 압축 방식. 주로 Content-Type과 같이 사용되며 참조되는 미디어 타입을 얻도록 디코드하는 방법을 클라이언트가 알게 해줌
- Location : 301, 302 상태코드일 때만 볼 수 있는 헤더로 서버의 응답이 다른 곳에 있다고 알려주면서 해당 위치(URI)를 지정
- Last-Modified : 리소스의 마지막 수정 날짜
- Allow : 지원되는 HTTP 요청 메소드 ex) GET, HEAD, POST
- Expires : 리소스 만료 일자
- ETag : 리소스의 버전을 식별하는 고유한 문자열 검사기(주로 캐시 확인용으로 사용)
Body
HTTP Request가 전송하는 데이터를 담고 있는 부분으로 전송하는 데이터가 없다면 비어 있다. POST 요청인 경우, HTML 폼 데이터가 포함되어 있다.
POST /test HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 83
Content-Type: application/json
Host: google.com
User-Agent: HTTPie/0.9.3
{
"test_id": "tmp_1234567",
"order_id": "8237352"
}HTTP Response의 구조
일반적인 HTTP Response에는 HTTP 상태 코드(status line), HTTP 응답 헤더(headers), blank line, 선택 사항인 HTTP 본문(body)이 포함된다.
Status Line
HTTP Response의 상태를 간략하게 나타내 주는 부분으로, HTTP version, Status code, Status Text의 3가지 부분으로 나뉘어져 있다.
HTTP/1.1 200 OK
[HTTP version] [Status Code] [Status Text]💭Statue Code
: 클라이언트가 보낸 Request의 처리 상태를 Response로 알려주는 기능
HTTP response status codes
- 200번대(성공)
- 200 OK : 성공적으로 요청되었음
- 201 Created : 요청에 의해 자원이 생성되었음
- 202 Accpeted : 요청이 접수되었으나 처리가 완료되지 않았음
- 204 No Content : 서버가 요청을 수행했으나 본문에 보낼 데이터가 없음
- 300번대(리다이렉션) : location header가 있으면 location 위치로 자동 이동
- 301 Moved Permanently : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
- 302 Found : 요청한 리소스의 URI가 일시적으로 변경되었음
- 303 See Other : 클라이언트가 요청한 리소스를 다른 URI에서 GET 요청을 통해 얻어야 할 때 서버가 클라이언트로 직접 보내는 응답
- 304 Not Modified : 캐시를 목적으로 사용. 응답이 수정되지 않았음을 알림
- 400번대(클라이언트 측에서 오류가 발생)
- 400 Bad Request : 클라이언트가 잘못된 요청을 해서 서버가 요청을 이해할 수 없음
- 401 Unauthorized : 클라이언트가 해당 리소스에 대한 인증이 필요함
- 403 Forbidden : 서버가 요청을 이해했지만 승인을 거부함(미승인)
- 404 Not Found : 요청 리소스를 찾을 수 없음
- 500번대(서버 측에서 오류가 발생)
- 500 Internal Server Error : 서버 문제로 오류 발생. 처리 방법 알 수 없음.
- 502 Bad Gateway : 서버가 요청을 처리하는 데 필요한 응답을 얻기 위해 Gateway로 작업하는 동안 잘못된 응답을 수신했음
- 503 Service Unavailable : 서비스 이용 불가. 요청을 처리할 준비가 되지 않음.
Header
💭Response Header
: 위치 또는 서버 자체에 대한 정보(이름, 버전)과 같이 응답에 대한 부가적인 정보를 갖는 헤더
- Server : 웹서버의 종류. Request Header의 User-Agent 대신 사용되는 부분.
- Age : max-age 시간내에서 얼마나 흘렀는지 초 단위로 알려주는 값
- Referrer-policy : 서버 referrer 정책을 알려주는 값 ex) origin, no--referrer, unsafe-url
- WWW-Authenticate : 사용자 인증이 필요한 자원을 요구할 시, 서버가 제공하는 인증 방식
- Proxy-Authenticate : 요청한 서버가 프록시 서버인 경우 유저 인증을 위한 값
- Set-Cookie : 서버측에서 클라이언트에게 세션 쿠키 정보를 설정 (RFC 2965에서 규정)
Body
데이터를 전송할 필요가 없을 경우 body가 비어 있으며 Request의 body와 일반적으로 동일하다.
HTTP의 특징
1. Client - Server 구조
- client가 server에 요청(request)을 보내고 응답을 대기한다.
- server가 요청에 대한 결과를 만들어 응답(response)한다.
2. 무상태 프로토콜(Stateless)
통신이 끝나면 상태를 유지하지 않는 속성, 연결을 끊는 순간 상태정보를 유지하지 않는 특성. Server는 Client의 상태를 보존하지 않는다.
- 서버 확장성이 높다. 무상태는 응답 서버를 쉽게 바꿀 수 있으므로 무한한 서버 증설 가능(스케일 아웃)
- 클라이언트가 추가 데이터를 전송해야 한다는 한계가 존재함.
- 로그인과 같이 유저 상태를 유지해야 하는 경우 브라우저 쿠키, 서버, 세션, 토큰 등을 이용해 상태를 유지해야 함.
3. 비연결성(Connectionless)
client가 request를 보내고, server가 response를 하면 그 연결을 끊어버린다.
기본적으로 HTTP는 연결을 유지하지 않는 모델이다.(응답을 준 뒤 TCP/IP 연결을 끊어 최소한의 자원으로 서버를 유지함)
- 트래픽이 많지 않고, 빠른 응답을 제공할 수 있는 경우 효율적으로 작동
- 트래픽이 많고 큰 규모의 서비스를 운영할 때 한계를 보임.
- HTTP 1.1에서 HTTP 지속 연결이 가능해지며 자원을 보낼 때마다 TCP/IP 연결을 새로 맺어야 하는 문제를 해결할 수 있어졌다.
2. API(Application Programming Interface)
- 애플리케이션은 고유한 기능을 가진 모든 소프트웨어
- 인터페이스는 두 애플리케이션 간의 서비스 계약을 의미
- 계약은 요청과 응답을 사용해 두 애플리케이션이 서로 통신하는 방법을 정의
- API 문서에는 개발자가 이러한 요청과 응답을 구성하는 방법에 대한 정보가 포함됨
- 일반적으로 HTTP 프로토콜과 JSON을 기반으로 통신하는 HTTP(REST) API로 서버를 구축함.
API 작동 방식(아키텍처 주요 유형)
SOAP API, RPC API, Websocket API, REST API의 4가지 방식으로 작동할 수 있음
SOAP API
: 단순 객체 접근 프로토콜. 클라이언트와 서버가 XML을 사용해 메시지를 교환하며 과거에 더 많이 사용되었음. 유연성이 떨어지는 API
RPC API
: 원격 프로시저 호출. 클라이언트가 서버에서 함수나 프로시저를 완료하면 서버가 출력을 클라이언트로 다시 전송
Websocket API
: JSON 객체를 사용해 데이터를 전달하는 최신 웹 API. 클라이언트 앱과 서버 간의 양방향 통신을 지원하며 서버가 연결된 클라이언트에 콜백 메시지를 전송할 수 있어 가장 효율적임.
REST API(RESTful API)
: 가장 많이 사용되고 유연한 API. 클라이언트가 서버에 요청을 데이터로 전송하면, 서버가 이 클라이언트 입력을 사용해 내부 함수를 시작하고 출력 데이터를 다시 클라이언트에 반환함
API의 유형(사용 범위)
프라이빗 API, 퍼블릭 API, 파트너 API, 복합 API의 4가지 유형이 있음
프라이빗 API
: 기업 내부에 있으며 비즈니스 내에서 시스템과 데이터를 연결하는 데만 사용
퍼블릭 API
: 일반에 공개되며 누구나 사용할 수 있음. 이러한 유형의 API와 관련된 권한 부여와 비용이 있을 수도 있고 없을 수도 있음.
파트너 API
: B2B 파트너십을 지원하기 위해 권한이 부여된 외부 개발자만 액세스 가능함
복합 API
: 두 개 이상의 서로 다른 API를 력ㄹ합하여 복잡한 시스템 요구 사항이나 동작을 처리
참고자료
HTTP란 무엇입니까?
프로토콜이란? | 네트워크 프로토콜의 정의
[TIL — NETWORK] 인증, 인가, http 메서드, 상태코드
[간단정리] HTTP Request/Response 구조
HTTP의 특징
Method Definitions
HTTP Method : 안전(Safe), 멱등성(Idempotent), 캐시(Cacheable)
안전함 (HTTP 메서드)
HTTP Header에는 어떤 정보들이 담겨있을까
애플리케이션 프로그래밍 인터페이스(API)란 무엇인가요?
