Network)API

백준우·2021년 10월 19일

Network

목록 보기

3/6

학습 목표

1. REST API

2. Open API

들어가면서...

API(Application Programming Interface)는 어플리케이션 소프트웨어를 구축하고 통합하기 위한 정의 및 프로토콜 세트로, 많은 양의 Data를 사용할 수 있도록 규칙을 제공하는것이다.
API를 통해 지도,결재,채팅등 많은 Data들을 사용할 수 있습니다.

1. REST API

REST(Representational State Transfer)API는 웹의 장점을 최대한 활용할 수 있는 아키텍처로 로이 필딩의 박사학위 논문에서 처음 소개되었었다. 웹에서 사용하는 데이터 자원(Resource)를 HTTP URL로 표현하고,HTTP프로토콜을 통해 요청과 응답을 정의하는 방식을 말한다.
HTTP 프로토콜 기반으로 요청과 응답에 따라 리소스를 주고받기 위해서는 알아보기 쉽고 잘 작성된 규칙이 필요하며 이 역할을 API가 수행해야 하므로 규칙에 맞게 작성하는 것이 중요하다.
특징

균일한 인터페이스:요청이 어디에서 오는지와 무관하게, 동일한 리소스에 대한 모든 API 요청은 동일하게 보여야 합니다.
클라이언트-서버 디커플링: REST API 디자인에서, 클라이언트와 서버 애플리케이션은 서로 간에 완전히 독립적이어야 합니다.
Stateless(무상태성): REST API는 서버측 세션을 필요로 하지 않습니다. 세션정보등을 별도 저장하지 않으며 덕분에 서비스의 자유도가 높아짐
캐싱 가능성: 가급적이면, 리소스를 클라이언트 또는 서버측에서 캐싱할 수 있어야 합니다.
계층 구조 아키텍처: REST API에서는 호출과 응답이 서로 다른 계층을 통과합니다.
코드 온디맨드(옵션): REST API는 일반적으로 정적 리소스를 전송하지만, 특정한 경우에는 응답에 실행 코드(예: Java 애플릿)를 포함할 수도 있습니다. 이러한 경우에, 코드는 요청 시에만 실행되어야 합니다.

REST API 설계지침

리소스(URL)
리소스를 설명하려면 동작 동사가 아닌 구체적인 이름을 사용해야한다.
GET /users/1234, POST /users
URI케이스
프로그램 리소스를 명명할때 3가지 주요 유형의 규칙이 있습니다.
CamelCase: 첫글자는 대문자를 사용(시작 강조)
SnakeCase: ""로 단어를 구분하여줌
spine-Case: "-"를 사용하여 Snake_Case와 유사
HTTP메소드

이름	기능
Get	URL을 사용해서 정보를 검색할때 사용
Head	Get과 동일하지만 상태표시줄과 헤더섹션만 전송
Post	데이터를 서버로 보내는 데 사용
Put	대상 리소스의 모든 현재 표현을 업로드된 콘텐츠로 변경
Patch	리소스를 약간 업데이트 할때 사용, 멱등성 필요 없음
Delete	URL에서 제공하는 대상 리소스의 모든 현재 표현 삭제
Options	대상 리소스에 대한 통신 옵션을 설명

TIP)Put과 Post의 차이

Put은 요청이 위치에서 자원의 전체 내용을 대체
Patch는 위치에서 자원의 일부를 변경하는데 사용

HTTP헤더

HTTP 헤더 필드는 요청이나 응답, 또는 메시지 본문에서 보낸 객체에 대한 필수 정보를 제공
3.1 General Header: 요청,응답 메세지 모두에 일반적으로 적용가능
3.2 Client Request Header: 요청메세지에만 적용
3.3 Server Response Header: 응답 메세지에만 적용
3.4 Entity Header: entity-body정보를 정의하거나,Body가 없는경우 요청에 의해 식별된 리소스에 대한 정보를 정의합니다.

query매게변수
4.1 Paging:API초기 설계 단계에서는 리소스의 페이징을 예상해야한다.
반환될 데이터의 양의 진행상황 예측이 어려울경우 리소스를 기본값으로 페이지를 선정하는것이 좋다.
4.2 Filtering:일부속성과 예상값을 지정하여 쿼리된 리소스의 수를 제한하는것으로 구성된다.
4.3 Sorting: 정렬매개변수는 정렬이 수행되는 속성의 이름을 쉼표(,)로 구분하여 포함해야 합니다.
4.4 Searching:리소스 및 컬랙션 자체와 다른 형식을 갖고 검색과 관련된 제안,수정 및 정보를 추가할 수 있다.
상태코드

이때 REST API를 작성할때는 몇가지 규칙이 존재하며 이를 위해 4단계 모델을 만들었습니다.

!)0단계 : 0단계에서는 단순히 HTTP 프로토콜을 사용하기만 해도 됩니다. 물론 이 경우, 해당 API를 REST API라고 할 수는 없으며, 0단계는 좋은 REST API를 작성하기 위한 기본 단계입니다.

- Request
Post https://API/user HTTP/1.1
[헤더생략]
{
"Date":"2021-10-19"
"unsername":["baek"]
}
- Response
HTTP/1.1 200ok
[헤더생략]
{
"slots":[{"username":"baek",
"job":"programeer"]
}

!!)1단계: 1단계에서는 개별 리소스와의 통신을 준수해야 한다.
EX)엔드포인트를 사용,변경되는 리소스를 엔드포인트로 사용하는것입니다.

- Request
Post https://API/user/baek HTTP/1.1
[헤더생략]
{
"Date":"2021-10-19"
"unsername":["baek"]
}
- Response
HTTP/1.1 200ok
[헤더생략]
{
"slots":[{"username":"baek",
"job":"programeer"]
}

!!!)2단계: 2 단계에서는 HTTP method 인 GET, POST, PUT, DELETE 를 사용해서 CRUD 를 나타내며 메시지에 Status Code 도 담겨 반환된다.

- Request
Get https://API/user/baek HTTP/1.1
[헤더생략]
- Response
HTTP/1.1 201 Created
[헤더생략]
{
"slots":[{"username":"baek",
"job":"programeer"]
}

!!!)3단계: 마지막 단계는 HATEOAS(Hypertext As The Engine Of Application State)라는 약어로 표현되는 하이퍼미디어 컨트롤을 적용합니다. 3단계의 요청은 2단계와 동일하지만, 응답에는 리소스의 URI를 포함한 링크 요소를 삽입하여 작성한다는 것이 다르다.

- Request
Get https://API/user/baek HTTP/1.1
[헤더생략]
- Response
HTTP/1.1 201 Created
[헤더생략]
{
"slots":[{"username":"baek",
"job":"programeer"]
"links":{
    ...}
}