[HTTP/네트워크] 실습

Chapter1. REST API
1.REST API에 대해 이해할 수 있다.
2.REST 성숙도 모델에 대해 이해할 수 있다.
3.REST API 문서를 읽을 수 있다.
4.REST API에 맞춰 디자인할 수 있다.
5.Open API와 API Key에 대해 이해할 수 있다.

1.REST API(Representational State Transfer Aplication Programming Interpace)는 웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식을 말한다.

2.레오나르드 리차드슨(Leonard Richardson)은 REST API를 잘 적용하기 위한 4단계 모델을 만들었는데 0단계 HTTP 사용, 1단계 개별 리소스와의 통신 준수, 2단계 HTTP 메소드 원칙 준수, 3단계 HATEOAS 원칙 준수로 나뉘지만 2단계까지만 적용해도 좋은 API 디자인이라고 볼 수 있고, 이런 경우를 HTTP API 라고도 부른다.


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


1단계 - 개별 리소스와의 통신 준수
모든 자원은 개별 리소스에 맞는 엔드포인트(Endpoint)를 사용해야하며 요청하고 받는 자원에 대한 정보를 응답으로 전달해야 한다는 것이 1단계의 핵심이다. 
1단계에서는 요청하는 리소스가 무엇인지에 따라 각기 다른 엔드포인트로 구분하여 사용해야 하는데 어떤 리소스를 변화시키는지 혹은 어떤 응답이 제공되는지에 따라 각기 다른 엔드포인트를 사용하기 때문에, 적절한 엔드포인트를 작성하는 것이 중요하다.


2단계 - HTTP 메소드 원칙 준수
2단계에서는 CRUD에 맞게 적절한 HTTP 메서드를 사용하는 것에 중점을 두는데 아래와 같이 목적에 따라 해당하는 메서드를 선택해서 요청해야만 대체적으로 잘 작성된 API라고 할 수 있다.

GET 메서드는 특정 리소스의 표시를 요청합니다. GET을 사용하는 요청은 오직 데이터를 받기만 합니다.
HEAD 메서드는 GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않습니다.
POST 메서드는 특정 리소스에 엔티티를 제출할 때 쓰입니다. 이는 종종 서버의 상태의 변화나 부작용을 일으킵니다.
PUT 메서드는 목적 리소스 모든 현재 표시를 요청 payload로 바꿉니다.
DELETE 메서드는 특정 리소스를 삭제합니다.
CONNECT 메서드는 목적 리소스로 식별되는 서버로의 터널을 맺습니다.
OPTIONS 메서드는 목적 리소스의 통신을 설정하는 데 쓰입니다.
TRACE 메서드는 목적 리소스의 경로를 따라 메시지 loop-back 테스트를 합니다.
PATCH 메서드는 리소스의 부분만을 수정하는 데 쓰입니다.

또한 다음과 같은 주의사항이 있다.
GET 메서드 같은 경우는 서버의 데이터를 변화시키지 않는 요청에 사용해야 합니다.
POST 메서드는 요청마다 새로운 리소스를 생성하고 PUT 메서드는 요청마다 같은 리소스를 반환합니다. 이렇게 매 요청마다 같은 리소스를 반환하는 특징을 멱등(idempotent)하다고 합니다. 그렇기 때문에 멱등성을 가지는 메서드 PUT과 그렇지 않은 메서드POST는 구분하여 사용해야 합니다.
PUT 메서드와 PATCH 메서드도 구분하여 사용해야 합니다. PUT은 교체, PATCH는 수정의 용도로 사용합니다.



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



전체적으로 정리를 하며 본 결과 3단계를 잘 이용하지 않는 이유는 3단계 내부의 원칙이 정확하게 정립되지 않았기 때문이 아닌가 싶다.
어차피 요청과 응답을 통해 값을 받아서 그 주소에 접근할 수 있다면 3단계가 굳이 필요하지 않을 수 있으며 사람이 눈으로 요청과 응답을 처리하는 것이 아닌데 HATEOAS의 규격을 정확하게 정해두지 않는다거나 오류가 발생한다면 그 부분을 조회하며 다시 전단계의 정보를 찾아야 하는 문제도 발생할 수 있을 것 같다.

3.API문서를 보고 요청, 응답을 구분할 수 있으며 어떤 목적인지 대략적으로 추측할 수 있고(API 규정을 잘 지켰다면) 에러코드도 조금은 안다.

4.@@@@아직 과정이 추가적으로 진행되지 않아서 이론만 하고 실제 적용은 다음주에 하기 때문에 아직은 잘 할 수 없는 상태다.

5.Open API
정부에서 제공하는 공공데이터는 쉽게 접근할 수 있도록 Open API형태로 제공되는데 공공데이터 포털에 접속해 원하는 키워드를 검색하면, 해당 키워드와 관련된 API를 확인할 수 있다.
Open이라는 단어의 이미지와는 다르게  API마다 정해진 이용 수칙이 있고, 그 이용 수칙에 따라 제한사항(가격, 정보의 제한 등)이 있을 수 있다.
API Key
API를 이용하기 위해서는 서버의 문을 열 수 있는 API key가 필요하다.( key를 요구하지 않는 경우도 있음)
API Key가 필요한 경우에는 로그인한 이용자에게 자원에 접근할 수 있는 권한을 API Key의 형태로 제공하고, 데이터를 요청할 때 API key를 같이 전달해야 원하는 응답을 받을 수 있다.

 

수업 중 블로깅 시간이 있었기 때문에 내용에 대해 조금 더 거창하게 답변이 된 것 같다.

다음주 월요일에 과제를 하고 오늘은 이론만 보는 과정이라서 조금 자신은 없지만

이론적으로는 크게 어렵지는 않을 것 같다.