RestAPI란

출처: https://velog.io/@soom/REST-Representational-State-Transfer

Rest란

representation state transfer의 약자로

프로토콜이나 표준이 아니고 아키텍쳐 원칙이다.

api 개발자는 rest를 다양한 방식으로 구현할수있다.

자원을 자원의 표현(representaiton)으로 구분하며 해당 자원의 상태(정보)를 주고받는 모든것을 의미한다

 

자원(resource)

• 모든 자원에는 고유한 아이디가 존제한다.
• 자원에 접근은 /users/:userId 이런식으로 http URI이다
• client는 uri를 통해서 자원에 대한 조작을 server에 요청한다.

행위(method)

행위는 HTTP 메소드를 사용한다.

• Method
  
  GET 
  • 리소스를 조회한다.
  • 서버에 전달하고 싶은 데이터는 qeury(쿼리 파라미터, 쿼리 스트링)를 통해서 전달한다.
  • 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장되지 않는다.
  POST
  • 새 리소스를 생성할 때 사용한다.
  • 메시지 바디를 통해 서버로 요청 데이터를 전달하고 처리하는데 사용한다. 단순히 데이터를 생성하거나 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우가 해당한다. POST의 결과로 항상 새로운 리소스가 생성되는 것은 아니다.
  • JSON으로 조회 데이터를 넘겨야 하는데 GET 메서드를 사용하기 어려운 경우 등, 다른 메서드로 처리하기 애매한 경우 사용한다.
  PUT
  • 리소스를 대체한다.
  • 리소스가 없는 경우 생성한다.
  • 클라이언트가 리소스 위치를 알고 URI를 지정하는 점이 POST와의 차이점이다.
  • PATCH와의 차이점은, 리소스를 일부만 변경하는 경우에도 바뀌지 않는 속성을 모두 보내야 한다는 점이다.
  PATCH
  • 리소스를 부분적으로 변경한다.
  • PUT과 달리, 변경할 값만 보내면 된다.
  DELETE
  • 리소스를 삭제한다.
  HEAD
  • GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환한다.
  OPTIONS
  • 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명한다.
  • 주로 CORS에서 사용한다.
  CONNECT
  • 대상 자원으로 식별되는 서버에 대한 터널을 설정한다.
  TRACE
  • 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행한다
    
    

표현(representation)

• 클라이언트가 자원에 대한 요청을 보내면 서버는 이에 대한 적절한 응답(response)을 해준다
• JSON,XML을 통해서 자원을 주고 받는것이 일반적이다.

 

 

 

 

 

 

 

 

 

 

 

아래는 restAPI 설계원칙입니다

• API 설계의 원칙
  1. URI 는 정보의 리소스를 표현해야 한다.
  • 행위에 대한 표현이 아닌 리소스를 표현하는데 중점을 두어야 한다.
  • 리소스명은 동사보다 명사를 사용한다.
  1. 리소스에 대한 행위는 HTTP Method로 표현한다. Method [ Create / Read / Update / Delete / HEAD / OPTIONS / CONNECT / TARCE] method 에 대한 설명 [[HTTP Method]]
  2. ( / ) 구분자는 계층 관계를 내포
  3. URI의 마지막 문자로 ( / )를 포함하지 않는다.
  4. ( - )은 URI의 가독성을 높이는데 사용 할 수 있다.
  5. ( _ )는 URI에 사용하지 않는다.
  6. URI 경로는 소문자를 사용한다,
  • RFC3986(URI 문법 형식)은 schema 와 Host를 제외하고는 upper와 lower를 구별하도록 규정
  • IETF 에서 2005년에 발표된 'Uniform Resource Identifier (URI): Generic Syntax' 협약 규정 [[https://www.rfc-editor.org/rfc/rfc3986]]
  1. 파일확장자는 URI에 포함시키지 아니한다.
  • 대신 Accept header를 사용.
    • HTTP header
      • Accept header
        • 브라우저에서 웹서버로 req message 에 담기는 header
        • 브라우져가 req message의 Accept header값을 application/json이라고 설정하였다면 '나는 json 데이터만 처리할 수 있으니 json 데이터 형식으로 응답을 돌려줘'라는 것과 같음 http://restapi.example.com/members/soccer/345/pthoto.jpg(X) GET /members/soccer/345/photo HTTP/1.1 (O) Host restapi.example.com Accept: image/jpg
      • Content-Type header
        • HTTP 메시지(req,res)에 담겨 보내는 데이터의 형식을 알려주는 헤더
        • 대부분의 브라우져 및 웹은 Content-Type header를 기준으로 메세지에 담긴 데이터를 분석하고, 파싱함
        • HTTP req의 GET방식인 경우 무조건 URL 끝에 query string 으로 key = value 로 날아가기 때문에 Content-Type header가 필요 없음
        • Content - Type는 POST / PUT 처럼 req.body에 실어 보내는 경우에 중요 <form> tag를 통해 첨부파일 전송의 경우라면 브라우저가 자동으로 > multipart/form-data로 설정 하여 req message를 보냄