REST API 대충 훑어보기

REST API를 대충 한번 알아보자

API (Application Programming Interface)

• 서로 다른 프로그램간에 소통이 가능하게 도와주는 통신규약
• 웹에서는 '서버와 클라이언트간 통신 규약'이라고 보면 된다.
• 즉, 서버에 요청해서 데이터 가져오는 방법이다.

REST API (Representational State Transfer)

• 로이 필딩이 2000년도 웹설계를 효율적으로 사용하기위해 만든 API디자인 방법이다.
• 지금은 거의 정론이 되어 다들 이 방법을 많이 사용한다.
• 관련된
• Rest API 규칙은 다음과 같다.

1. Uniform Interface

   • 클라이언트에 보낼 때는 이해가능한 포맷으로, 즉 json, html, XML과 같은 형식으로만 응답을 보내준다.
   • 응답 시 GET이라면 그에대한 부분만 아니고, 수정이나 삭제와 같은 부분도 요청을 어떤식으로 해야할 지 설명을 해주어야한다.
   • 응답시 그 데이터의 처리 방법을 포함해야 한다.
   • 클라이언트가 어떤 요청을 하고싶을 때, 그 키워드같은거로 요청을 보내면, 그에대한 방법들을 links에 넣어 보내주어야한다.

2. Client-server 구분

   • 고객들은 URL하나만 알면 서버의 자료를 사용할 수 있다.
   • 클라이언트에게 서버역할을 주거나, DB의 자료를 직접 꺼내게 하면 안된다.

3. Stateless

   • 요청들은 각각 독립적으로 처리해야 한다.
   • 요청들이 서로간에 의존성이 존재하면 안된다.

4. Cacheable

   • 요청을 통해 보내는 자료는 캐싱이 가능해야 한다.
   • 캐싱이 가능하다고 표시해야 한다.
   • 캐싱 기간도 설정

   캐싱: 브라우저에서 자주 사용하는 이미지나 css등을 하드에 저장해놓는다. 하드에 저장된 친구들은 요청하지 않고 하드에서 불러오는 행위

5. Layered System

   • 요청을 처리하는 곳, DB에 저장하는 곳 이런 여러 단계를 거쳐서 처리해도 된다.
   • 여러개의 레이어를 거쳐서 요청을 처리 해도 ㄱㅊ다

6. Code on Demand

   • 서버는 고객에게 실제 실행가능한 코드를 전송해 줄 수도 있다.

URL이름 짓기 관습

ex)
instagram.com/explore/tags/kpop
instagram.com/explore/tags/food
facebook.com/natgeo/photos
facebook.com/bbc/photos
위 예시처럼 한눈에 보이는 방식으로 작성한다.

• 단어들을 동사보다 명사로
• 응용해서 다른 정보를 쉽게 가져오게 일관성있게
• 대충봐도 예측 가능하게

1. 띄워쓰기는 _대신 -로 작정한다.
2. 파일확장자 금지 (ex .html)
3. 하위 문서는 /기호 사용

웹 API Designing

1. restful한 api를 사용하게되면 요청에 이미 GET, POST, PUT, DELETE로 행위를 표현하므로, url에는 이와같은 부분은 포함하지 않는다.

(ex)
// bad
GET: /posts/getPosts

// good
GET: /posts
GET: /posts/1

2. 필요한 부분을 url로 적고 그 상세한 부분은 쿼리를 사용한다.

(ex)
// bad
/posts/:id/tags

// good
/tags/?id=1

youtube api나 githubAPI같은 문서를 확인해보면 더 상세하게 예시들을 알 수 있다.

• https://developers.google.com/youtube/v3/docs/videos/list?hl=ko
• https://docs.github.com/ko/rest?apiVersion=2022-11-28