반응형

REST (Representational State Transfer)

REST API는 웹에서 데이터를 전송 및 처리하는 방법을 정의한 인터페이스를 말한다. 모든 데이터 구조와 처리방식은 REST에서 URL을 통해 정의되며, 그래서 매우 직관적으로 이해할 수 있다.

 

HTTP Method와 CRUD

일반적으로 API를 설계할때, URL로는 자원(resource)을 명시하고, HTTP Method로는 행위를 명시합니다.

 

REST 구성

  • 자원(resource): URI
  • 행위(verb): HTTP Method
    • HTTP Method를 통해 해당 자원에 대한 CRUD Operation을 적용하여 아래와 같이 사용한다.
      • Create: 데이터 생성 (POST)
      • Read: 데이터 조회 (GET)
      • Update: 데이터 수정 (PUT)
      • Delete: 데이터 삭제 (DELETE)

 

API 설계시 멱등성을 고려
- 멱등성: 동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때 해당 HTTP 메서드가 멱등성을 가졌다고 말한다.
- 올바르게 구현하는 경우, GET, HEAD, PUT, DELETE 메서드는 멱등성을 가지고, POST 메서드는 멱등성을 가지지 않는다.
- 참고: https://developer.mozilla.org/ko/docs/Glossary/Idempotent

 

GET Method

GET은 보통 조회를 할 때 사용한다.

  • DB로 생각했을때는 SELECT에 해당

 

예를들어, 회원가입한 사용자의 정보를 알고 싶다면, 아래처럼 사용한다.

GET http://localhost:8080/rest/api/v1/user/1

 

POST Method

POST는 보통 데이터를 추가할 때 사용한다.

  • DB로 생각했을때는 INSERT에 해당

회원 가입을 하는 경우, POST 방식으로 사용자의 정보를 함께 전송한다.

POST http://localhost:8080/rest/api/v1/user

{
    "username": "아무개",
    "password": "1234",
    "email": "test@google.com",
    ...
 }

 

보통 생성 과정이 성공적으로 끝나면, 응답값으로 201 CREATED를 보낸다. (아래 글 참고, 출처: MSDN)

출처: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201

 

PUT Method

PUT은 데이터를 수정 할 때 사용한다.

  • DB로 생각했을때는 UPDATE에 해당

 

사용자의 정보를 수정하고 싶은 경우, 수정하고 싶은 사용자 정보와 함께 PUT 방식으로 요청한다.

  • 위 POST와 동일한 URL로 요청하지만, HTTP 메소드가 다르기 때문에 다르게 동작한다.
PUT http://localhost:8080/rest/api/v1/user/{user_id}

예시: PUT http://localhost:8080/rest/api/v1/user/1

{
    "password": "4321"
 }

 

DELETE Method

DELETE는 데이터를 삭제할 때 사용한다.

  • DB로 생각했을때는 DELETE에 해당

 

사용자의 정보를 지우고 싶은 경우(탈퇴 처리) , DELETE 방식으로 사용자의 ID의 값과 함께 요청한다.

DELETE http://localhost:8080/rest/api/v1/user/{user_id}

예시: DELETE http://localhost:8080/rest/api/v1/user/1

 

응답코드

  • 200 : 클라이언트 요청 정상수행 (응답에 대한 메시지가 포함)
  • 201 : 리소스 생성 요청에 대한 정상처리
  • 202 : 리소스 생성 요청이 비동기적으로 처리될 때 사용
  • 204 : 클라이언트 요청 정상수행 (응답에 대한 메시지 미포함, 보통 삭제요청에 사용)
  • 400 : 클라이언트 요청이 부적절할 때 사용 (부적절한 이유를 응답 Body에 넣어줘야 함)
  • 401 : 클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청할 때 사용
  • 403 : 클라이언트가 인증상태와 무관하게 응답하고 싶지 않은 리소스를 요청할 때 사용 (400 사용을 권장)
  • 404 : 클라이언트가 요청한 리소스가 존재하지 않을 때 사용
  • 405 : 클라이언트가 불가능한 메소드를 사용했을 때

 

Reference

http://www.incodom.kr/REST

 

반응형

  • reply profile image

    소년택이

    GET / POST 는 조회 vs 생성 관점 보다는 "멱등성" 관점에서 이해하는게 좋습니다. A라는 동작을 취하면 B란 결과가 나온다고 가정할때, 동일한 조건으로 다시 A를 수행하여 B가 나온는걸 "멱등하다"라고 하구요, 그런 멱등성을 유지하는 경우 GET, 그렇지 아니한 경우에는 POST를 씁니다.

    예를 들어 볼께요.
    방문자 카운터가 있는데 관리자 페이지에서 현재까지 방문자 숫자를 조회하고자 합니다. 이 경우 GET 이겠죠? 그런데 일반 방문자가 접속하면 방문자 숫자는 하나 올라가고 방문자 숫자를 반환합니다. 이 경우 POST 입니다. 같은 /counter API, 같은 타입의 결과지만 GET으로 호출하느냐, POST로 호출하느냐에 따라 동작을 다르게 정의해야겠죠.

    물론 이것도 애매하긴 합니다. 만약 인터넷 뉴스를 조회하는데, 백날 조회해도 내용은 그대로겠죠? 물론 내가 조회하고 있는 도중에 기자가 기사를 수정했다면... 이건 내가 벌인 일이 아니라, 다른 사용자가 벌인 일이니 멱등성을 침해한다고 보지 않습니다. 하지만 내가 조회할 때 마다 조회수가 올라간다면... 이건 멱등성을 위배하는, 즉 POST 행위 일까요? 사실 저도 웹 개발자가 아니라서 이렇게 까지 고려해본 적은 없네요.

    참고로... RESTful 개념이 정립 되기 이전 아주 옛날에는... 정적 컨텐츠는 GET, 동적 컨텐츠는 POST 이렇게 쓰곤 했었답니다.

    • reply profile image

      Bluemiv

      답변이 늦었네요. 멱등성에 대해서는 모르는 부분이었는데, 새로운 지식을 알게됐습니다. 이 점 감사드립니다.

      찾아보다가 알게되었는데, 동일한 요청을 보냈을때 동일한 행위를 하고, Side Effect가 없는 경우 '멱등성'을 가진다는 것을 알았습니다.

      위에서 말씀하신 예제에서 뉴스를 조회했을때, '내가 데이터를 수정했느냐, 다른사람이 데이터를 수정했느냐'가 중요한것이 아니라, 데이터 내용(기사 내용)에 상관없이 '기사 내용을 반환한다'는 동일한 행위를 했기 때문에 멱등성을 가지는것이 맞다고 생각을 합니다.

      그리고, 기사를 조회할때 기사 내용을 반환하는데, 조회수도 같이 올라간다는 Side Effect가 발생한다면 이 부분은 멱등성을 침해한다고 생각합니다. 그래서 뉴스 기사를 조회하는 GET API와 조회수를 변경하는 PUT API를 따로 나눠서 만들어야 하지 않을까 생각이 드네요.

      저도 모르는 부분이 많아서, 한번 위와같이 생각해봤습니다. 다른 의견 있으면 답글 부탁드릴께요 :)

복사했습니다!