REST API
REST API는 웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식
REST API를 창시한 로이필딩은 위 모델의 모든 단계를 충족해야 REST API라고 부를 수 있다고 주장했다. 하지만 실제로는 모든 단계를 충족시키기 어렵기 때문에 2단계까지만 충족해도 좋은 디자인이라고 본다.
REST 성숙도 모델
0단계
0단계에서는 단순히 HTTP 프로토콜을 사용하기만 해도 되며, 이 경우에는 REST API라고 하지는 않는다.
위 예제에서는 POST method로 요청을 보내고 상태코드로 200을 응답받는 상황,
즉 HTTP 프로토콜만을 사용하고 있다.
1단계
1단계에서는 전 단계에서와는 달리 개별 리소스와의 통신을 준수해야 한다.
요청하는 리소스가 무엇이냐에 따라 엔드포인트도 각기 다르다(/appointment, /slots)
엔드포인트 작성시 동사나 어떤 행위에 대한 단어 사용은 지양해야 하며, 리소스 자체에 집중해서 명사로 작성해야 한다.
2단계
2단계에서는 CRUD에 맞게 적절한 HTTP 메소드 사용에 중점을 둔다.
예를 들어 조회(READ)를 위해서는 GET 메소드를 이용해야 하는데 이 경우에는 body를 가지지 않기 때문에 query parameter를 사용해서 필요한 리소스를 전달한다.
HTTP 메소드 사용 시 주의할 점
-
GET메소드 같은 경우에는 서버 데이터를 변화시키지 않는 요청에 사용해야 한다. -
PUT과POST차이POST : Request(요청)에 포함된 Entity(Http body에 해당)을 Request-URI에 정의된 리소스의 하위(Suboridiate) Entity로 새롭게 생성하는 요청을 서버에 보낼때 사용되는 Http Method이다.
POST의 경우에는 요청 시 마다 새로운 리소스를 받기 때문에 매 요청마다 같은 리소스를 반환하는 특징인 멱등성에 부합하지 않는다.
PUT : Request-URI에 있는 Resource가 존재한다면, Request에 있는 Entity에 값으로 리소스를 Update(갱신)한다.
PUT의 경우에는 요청이 계속 들어와도 같은 리소스를 반환하기 때문에 멱등성을 지닌다고 할 수 있다.
PUT vs PATCH
간단히 얘기하면 PUT은 리소스의 모든 부분이 필요하고 PATCH는 일부만 필요하다.
GET /users/1
{
"name" : "insutance",
"email" : "test@naver.com"
}이러한 데이터가 있다고 했을 때
PUT /users/1
{
"name" : "choi",
}
# result
GET /users/1
{
"name" : "choi",
"email" : null
}이처럼 PUT을 쓸 때는 name,email을 다 써줘야 하는데 하나라도 빠지면 null을 받게 된다.
3단계
2단계와 비슷하지만 응답에는 리소스의 URI를 포함한 링크 요소를 넣어서 작성해야 한다.
Open API
정부나 게임회사 등에서 제공하는 데이터가 있는데 이를 Open API 형태로 주게 된다.
예를 들면 Riot Developer Portal이라는 사이트를 들어가보면
이렇게 나와있는 것을 확인할 수 있는데, 프로젝트 목적에 맞게 사용하면 된다.
API Key
API를 이용하기 위해서는 API Key라는 것이 필요한데 서버를 여는 열쇠라고 보면 된다.
간혹 API Key가 필요하지 않은 경우도 있는데,ㅡ그 외에 웬만한 사이트는 다 있다.
무단 침입은 안되니까(?)
나는 사실 API를 그렇게 많이 다뤄보진 않았고, 또 당연한 소리겠지만 API Key를 외부에 노출시키면 큰일난다... 해커들이 좋아함
날씨 앱 같은 경우에는 프론트에서 막을 방법은 없다고는 하는데 다른 경우에는 금하고 있다.
참고자료
https://kingjakeu.github.io/study/2020/07/15/http-post-put/
https://velog.io/@insutance/REST-API-HTTP-Method-PUT-vs-PATCH
