웹개발을 하다보면서 API에 대해서 자연스럽게 알게되었다.
하지만 나아가 RestAPI라는것도 들어보았는데, 정확한 정의가 서지 않아 정리하고자 한다.
API(Application Programming Interface)
API(application programming interface 애플리케이션 프로그래밍 인터페이스[*], 응용 프로그램 프로그래밍 인터페이스)는 컴퓨터나 컴퓨터 프로그램 사이의 연결이다. 일종의 소프트웨어 인터페이스이며 다른 종류의 소프트웨어에 서비스를 제공한다. - 위키백과-
위키백과에서는 다음과 같이 정의하고 있다. 즉 일종의 연결다리 역할을 하는것이다.
일반적으로 웹에서는 프론트와 백엔드를 나누는데 프론트와 백엔드 사이의 통신을 하기 위해서API를 사용한다.
- > 중재자 역할
위 손님-점원-요리사 관계를 보면 쉬울것이다. 해당 그림에서는 점원이 API라고 할 수 있다.
RestAPI
Rest =(Representational State Transfer)
즉, RestApI는 자원의 상태를 주고받는 API를 뜻한다.
*Representational State Transfer(REST)는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처입니다. REST는 처음에 인터넷과 같은 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어졌습니다. - aws korea-
Rest 구성요소
1. 자원(Resource): URI
Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
2. 행위(Verb): HTTP Method
HTTP Method를 사용한다. (GET, POST, PUT, DELETE)
3. 표현 or 내용(Representation of Resource)
Client가 자원의 상태(정보)에 대한 요청 <-> Server는 이에 적절한 응답(Representation)을 보낸다.
REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다.
RestAPI 설계시 고려할 것
- HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
- HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
- 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미한다.
RestAPI 특징
1) Uniform (유니폼 인터페이스)
URI에 대한 요청을 통일되고(Uniform) 한정적인 아키텍쳐 스타일을 가진다.
-> 모바일, 웹 뭐든간에 특정기술에 종속되지 않는다.
2) Stateless (무상태성)
API 서버는 들어오는 요청만을 처리. 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순하다.
-> stateful과 반대되는 개념 -> 상태정보를 저장 및 관리 하지 않음
3) Cacheable (캐시 가능)
HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능하다.
-> HTTP에서 제공하는 캐싱기능 그대로 사용가능
4) Self-descriptiveness (자체 표현 구조)
REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것입니다.
5) Client - Server 구조
REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분됨
->클라이언트와 서버간의 의존성을 줄여줌
6) 계층형 구조
REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.
ex)nginx
클라이언트가 RESTAPI 사용시 필요한 리소스
1. 고유 식별자 리소스
일반적인 RESTAPI에서는 URL(Uniform Resource Locator)를 사용하여 리소스를 식별한다.
URL은 엔드포인트라고도하며 클라이언트가 요구하는 리소스를 표시한다.
ex)https://www.google.com/search .....
2.메서드
일반적으로 RESTAPI를 HTTP를 사용하여 구한다. 그 중에서 GET, POST, PUT, DELETE를 사용하여 구현한다.
- GET(조회-멱등성 보장O)
클라이언트는 GET을 사용하여 서버의 지정된 URL에 있는 리소스에 액세하여 데이터를 조회한다. GET 요청을 캐싱하 고 RESTful API 요청에 파라미터를 넣어 전송하여 전송 전에 데이터를 필터링하도록 서버에 지시할 수 있다.
- POST(생성-멱등성 보장X)
클라이언트는 POST를 사용하여 서버에 데이터를 전송합니다. 여기에는 요청과 함께 데이터 표현이 포함됩니다. 동일한 POST 요청을 여러 번 전송하면 동일한 리소스를 여러 번 생성하는 부작용이 있습니다.
- PUT(수정-멱등성 보장O)
클라이언트는 PUT을 사용하여 서버의 기존 리소스를 업데이트한다. POST와 달리, RESTful 웹 서비스에서 동일한 PUT 요청을 여러 번 전송해도 결과는 동일하다.
- DELETE(삭제-멱등성 보장O)
클라이언트는 DELETE 요청을 사용하여 리소스를 제거한다. DELETE 요청은 서버 상태를 변경할 수 있습니다. 하지만 사용자에게 적절한 인증이 없으면 요청은 실패한다. -> statusCode로 표시가능
3.HTTP 헤더
요청 헤더는 클라이언트와 서버 간에 교환되는 메타데이터이다. 예를 들어, 요청 헤더는 요청 및 응답의 형식을 나타내고 요청 상태 등에 대한 정보를 제공합니다.
4.데이터
REST API 요청에는 POST, PUT 및 기타 HTTP 메서드가 성공적으로 작동하기 위한 데이터가 포함될 수 있다.
5.파라미터
RESTful API 요청에는 수행해야 할 작업에 대한 자세한 정보를 서버에 제공하는 파라미터가 포함될 수 있다.
- URL 세부정보를 지정하는 경로 파라미터.
- 리소스에 대한 추가 정보를 요청하는 쿼리 파라미터.
- 클라이언트를 빠르게 인증하는 쿠키 파라미터.
멱등성
위에서 멱등성이라는 사용하였는데
멱등성은?
여러번 적용되어도 상태가 변하지 않음
-> 클라이언트가 여러번 요청을 보내어도 서버에서 같은 효과를 가져야한다.
언급했듯이 POST를 제외하고 나머지 3개의 메서드(GET, PUT, DELETE)는 멱등성을 보장합니다.
*참고-안전한 메서드?
- 안전한 메소드는 서버의 상태를 아예 변경시키지 않습니다.
- 멱등한 메소드는 서버의 상태를 변경시킬 수도 있고, 시키지 않을 수도 있습니다. 다만, 우리가 요청한 사항은 에러가 나거나, 지연이 발생하지 않는 한 요청에 대한 서버의 상태는 항상 같습니다
*요청에 대한 서버 상태!! 중요 - GET,HEAD가 해당 예시 <-> UPDATE, POST, DELETE는 서버의 상태가 변경될 수있음
-> 이유는 GET같은 경우는 조회만 하기에 서버 상태정보가 변경되지 않음
멱등성의 예시
1. GET
GET /member/3클라이언트가 해당 url를 연속하게 보내어도 서버의 상태코드는 (예를들어 200)으로 동일함.
즉 위에서 정의한 여러번의 클라이언트 요청에도 서버는 같은 효과를 기대할 수 있다. -> 멱등성 보장
+ 서버상태 자체도 변경되지 않으므로 안전한 메소드라고 할 수 있다.
2.POST
POST /member클라이언트가 body값 예를들어
{ id:"TEST" passwd:"123"} 들고 여러번 요청한다면
서버는 각 요청마다 다른 응답을 나타낼 수 있으며 다른 효과를 지니게 된다.
그러므로 멱등성이 보장되지 않는다고 할 수 있다.
(서버 전체 상태자체는 변경되었기에 안전한 메서드는X)
3.PUT
PUT /member/passwd클라이언트가 body값 예를들어
{ id:"TEST" passwd:"123"} 를들고 서버에거 비밀번호 변경 요청을 한다면
서버는 각 요청마다 (만약 data가 없다면 생성한다고 서버에서 로직을 구현한 경우) 가
data는 항상 수정된 상태를 클라이언트에게 보여줌으로 (서버 전체 상태자체는 변경되었기에 안전한 메서드는X)
멱등성이 보장된다.
4.DELETE
DELETE /member/3클라이언트가 member의 PK값이 3인 data를 삭제한다고 요청한다면,
서버에서는 데이터가 존재하면 삭제하고 데이터가 존재하지 않으면 삭제처리를 진행하지 않지만
클라이언트 입장에서는 서버로부터 삭제되었다는 상태만을 받기에 멱등성을 보장한다.
서버 전체 상태자체는 변경되었기에 안전한 메서드는X
RESTAPI 에대해서 어느정도 알아봤는데 확실히 블로그에 정리하면서 지식을 정리하니까 애매한 부분이었던것이 잘 정리된거 같다
밑에 참고된 블로그 및 사이트가 더 잘 정리되어 있으니 한번 찾아보길
잘못된 정보있으면 댓글 주시면 감사하겠습니다.
참고
https://www.redhat.com/ko/topics/api/what-are-application-programming-interfaces
https://ko.wikipedia.org/wiki/API
'cs' 카테고리의 다른 글
| [API] RestfulAPI - 비밀번호 찾기 (0) | 2022.10.19 |
|---|
