RESTful한 API 설계

API, 처음 들었을 때 굉장히 있어보이면서 나랑은 친해지기 어려운 용어라고 생각했다.
사용자와 프로덕트간을 연결해주는 것을 UI(User Interface)라는 것은 익히 알고 있었지만
API라는 단어는 너무 생소하고 벽으로 느껴졌다.
계속 멀게만 느낄 수 없기에 드디어 API를 마주보고 파헤쳐보는 시간을 가지게 되었다.

API 란?

Application Programming Interface의 약자로 프로그램을 실행하는 인터페이스

RESTful API 란?

Representational State Transfer의 약자로
웹상에서 사용되는 여러 리소스를 HTTP URI로 표현하고 그 리소스에 대한 행위를 HTTP Method로 정의하는 방식.
즉, 리소스(HTTP URI로 정의된)를 어떻게 한다는 구조적으로(HTTP Method + Payload) 깔끔히 표현

-> uri 자체로 정보를 표현할 수 있어야한다

API :
GraphQL
gRPC
REST : 학습에 있어서 진입장벽이 낮다. 비싼 프로그램이 필요없다.

https://meetup.toast.com/posts/92

self descriptiveness

RESTful API 설계규칙
URI 정보를 명확하게 표현해야한다.

• resoude는 명사를 사용
  GET/user/1 -> GET/users/1

resource에 대한 행위를 HTTP Method (GET,POST, PUT, DELETE)로 표현한다.

GET : 조회 (받겠다)
POST : resource 생성 (보내겠다)
PUT : resource 전체 갱신 (놓겠다/ 넣겠다)
DELETE :resource 삭제 (지정한 서버의 파일을 삭제하겠다)

• URI 에 HTTP Method가 포함되서는 안된다.

• URI에 동사가 포함되서는 안된다.
  GET/user/show/1 -> GET/users/1
  POST insert/user/2 -> POST/users/2

• resouce 사이에 연관관계가 있는 경우
  리소스/고유ID/관계 있는 리소스
  GET/users/{use_id}/profile

• 파일의 경우 payload의 포맷을 나타내기 위한 파일 확장자를 URI에 포함시키지 않는다.
  GET user/1/proffile-photo.jpg -> GET user/1/proffile-photo

• URI는 / 구분자를 사용하여 자원의 계층 관계를 나타내는데 사용한다.

• URI 마지막 문자로 /를 포함하지 않는다.
  GET users/portfolios

• 불가피하게 URI가 길어지는 경우 -를 사용하여 가독성을 높인다.

• _ 는 사용하지 않는다.
  URI 경로에는 대문자 사용을 피하고 있다.

-> Best Practice
Query parameters -> Filtering, Sorting, Searching