🔗 API
API는 Application Programming Interface의 약자로 응용 프로그램 프로그래밍 인터페이스 입니다.
→ 응용프로그램에서 사용할 수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻합니다.
❓ 음..? 이게 뭔소리야?
쉽게 말하자면 API는 점원이라고도 할 수있습니다.
손님에게 존재하는 메뉴를 보여주고, 손님이 주문을 하면 주방장에게 전달해주는 역할을 하는 것입니다.
위에서 말했듯 API는 Application Programming Interface의 약자입니다. 여기서 Application / Programming 이 두개는 알겠는데... Interface...? 이건 과연 무엇일까요?
Interface
인터페이스는 중간에서 양쪽에 있는 친구들의 중재 / 매개체 가 되어주는 역할을 합니다.
- GUI : Graphic User Interface → 컴퓨터한테 명령을 내릴때 그래픽을 사용해서 명령을 내리는 방식
- CLI : Command Line Interface → 명령어 문장으로 컴퓨터한테 명령을 내리는 방식
🛏️ REST API
웹개발자는 무조건 HTTP를 지켜야합니다.
쉽게 말해서 인터넷 망 속에 가상공간을 설계하는 사람들은 인터넷을 뽈뽈뽈 돌아다니기 위한 규약을 지켜야한다는 것이죠.
그러나? 과거에는 HTTP 형식을 따르지 않고 대에충 끼워 넣었습니다.
이런 상황을 본 HTTP창시자는 말했죠
✔️ HTTP 창시자왈
"웹을 위한 규약을 좀 지켜 이제부터 RestAPI를 사용해서 HTTP형식을 좀 따랐음 좋겠어"
REST API특징
- 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다.
- REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있다.
- 즉, REST API를 제작하면 델파이 클라이언트 뿐 아니라, 자바, C#, 웹 등을 이용해 클라이언트를 제작할 수 있다.
😪 REST API VS RESTful API
이름은 비슷한데 뭐가 다른거지 ..?
- REST API : HTTP 규약을 잘 따른 API
- RESTful API : HTTP규약을 매우매우매우 잘 따른 API
🔗 HTTP 프로토콜 템플릿
HTTP통신 방식
- HTTP는 기본적으로 요청 / 응답 구조로 되어있습니다.
클라이언트가 HTTP request를 서버에 보내면 서버는 HTTP response를 보내는 구조. 클라이언트와 서버의 모든 통신이 요청과 응답으로 이루어집니다. - HTTP는 Stateless입니다.
Stateless란 말 그대로 state를 저장하지 않는다 라는 뜻입니다.
즉, 각각의 요청에 대해 대응은하나 여러 요청/응답 끼리 연결되어있지 않다는 것을 뜻합니다.
그래서 1초전에 보냈던 요청을 1초후에 보내게 된다해도 해당 응답에 대해 알지 못한다는 것입니다.
=> 그래서 나온게 쿠키 or 세션의 정의입니다.
HTTP Request 구조
HTTP 구조는 크게 3가지로 나뉩니다.
- start line
- headers
- body
- start line
말그대로 HTTP Request의 첫번째 라인 start line도 총 3가지로 분류되어있다.
- HTTP Method
- 해당 request가 의도한 action을 정의
- HTTP Method에는 GET / POST / PUT / DELETE / OPTIONS 등등이 존재한다.
- Request target
- 해당 request가 전송되는 목표 url (ex.login)
- HTTP Version
- 말 그대로 사용되는 HTTP 버전
- Headers
-
request에 대한 추가 정보를 담고있는 부분 (ex. Content-Length)
-
key: value로 이루어져 있다.
-
header도 크게 3부분으로 구성되어있다.
((general headers, request headers, entity headers) 하지만 디테일한건 몰라도된다.)자주 사용되는 header의 정보
- Host : 요청이 전송되는 target의 host url
- User-Agent : 요정을 보내는 클라이언트에 대한 정보 ( ex. 웹 브라우저에 대한 정보 )
- Accept : 해당 요청이 받을 수 있는 응답 타입
- Connection : 해당 요청이 끝난 후에 클라이언트와 서버가 계속해서 네트워크 연결을 유지할 것인지 아닌지에 대해 지시하는 부분
- Content-Type : 해당 요청이 보내는 메시지
Body의 타입 ( ex. JSON을 보내면 application/json ) - Content-Length : 메시지의
body길이
- Body
- 해당 request의 실제 메시지 / 내용
- Body가 없는 request도 많음
- GET request들은 대부분 body가 없는 경우가 많음
HTTP Response 구조
Response도 request와 마찬가지로 3가지 부분으로 구성되어 있다.
- Status line
- Headers
- Body
- Status Line
Response의 상태를 간단하게 나타내주는 부분.
3부분으로 구성되어있다.
- HTTP 버전
- Status code : 응답 상태를 나타내는 코드 ( 숫자로 되어있음 흔히알고있는 404 )
- Status text : 응답 상태를 간략하게 설명해주는 부분 ( ex. Not Found )
HTTP/1.1 404 Not Found
- Headers
- Request의 header와 동일하다
- 다만, response에서만 사용되는 header 값들이 있다. (Ex. User-Agent 대신 Server 헤더가 사용 )
- Body
- Request의 Body와 동일하다
- Request와 마찬가지로 모든 response body가 있지 않다. 데이터 전송할 필요가 없다면 비워두어도 괜찮다.
🍤 Url
URL은 Uniform Resource Locator 이다.
인터넷 상에서 웹 페이지가 어디있는지 위치를 알려주는 것 뿐만아니라 데이터 연산을 해달라고 서버에게 요청을 보내는 방법이다. -> 쉽게 말하면 웹페이지 주소라고 할 수있다.
또한, 사용자가 원하는 정보의 위치와 종류를 파악할 수 있도록 웹페이지의 정보구조를 반영한 것이다.
그렇기 때문에 웹페이지의 정보 구조가 제대로 반영된 URL은 좋은 UX이며 이는 SEO기획에서 중요한 지표이기도 하다.
결론
URL의 구성 및 구성 요소는 사용자 경험 / SEO / 웹사이트 보안에도 중요하다.
🍤 REST API Url 규칙
- 대문자 X / 소문자 O
- 언더바 (_) X / 하이픈 (-) O
- 마지막에 /(슬래시) 포함 X
- 목적을 포함하지 않는다.
- 파일 확장자 포함 X
- 복수형을 사용
- 사용이유 : 통일감
예시
- 상품등록
"POST"/product - 전체 상품 조회
"GET" / products - 전체 상품 삭제
"DELETE" /products - 상품 개별 조회
"GET" /product/{id} - 상품 개별 수정
"PUT" /product/{id}
☄️ HTTP Method
HTTP Method에는 여러가지가 존재합니다.
해당 포스트에서는 어떤것이 있는지 간단하게만 알아보고자 하고 다른 포스트에서 자세히 다루어보고자 합니다.
- GET : 조회
- POST : 등록
- PUT : 수정
- DELETE : 삭제
