REST API?

Intro

Simple API 과제의 PATCH Method 코드 부분
아래 주석처럼 REST API에 부합하기 위한 url을 설정해야 된다는 멘토님의 설명이 있었는데..
REST의 REST API 개념 공부가 필요한 시점이었다.

else if (method === 'PATCH') {
      if(url.startsWith('/post/list') ) { //path parameter **REST API 규약에 따라 유저 별 URI를 명시해야 한다.
       
        let body = "";

        request.on("data", (data) => {
          body += data;
        });

        request.on("end", () => {
          const postId = parseInt(url.split("/")[3]); //입력값의 유저의 확인 조건
          const patchData = JSON.parse(body);
          const post = data.find((x) => x.userID === postId); 
          
          response.writeHead(201, {'Content-Type' : 'application/json'})
          response.end(JSON.stringify({ post: data }));
        });
      }

전체 코드 Git-hub 링크

REST란?

"Representational State Transfer"의 약자로 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처이다. 자원을 이름으로 구분하여 정의하고 해당 자원의 상태를 주고 받는 모든 것을 의미한다.

• 서버 : HTTP URI(Uniform Resource Identifier)를 통해 Resource를 명시하고,
• 클라이언트의 Request : HTTP Method(GET, POST, PATCH, PUT, DELETE 등)를 통해
• 서버의 Response : 명시된 자원(URI)를 통해 CRUD Operation을 적용하는 것을 의미한다.

위와 같은 구조를 지침으로한 네트워크 상에서 클라이언트와 서버사이의 통신 방식중 하나이다.

장점

• HTTP 프로토콜의 인프라를 그대로 사용하여 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다.
• HTTP 프로토콜을 따르는 다양한 플랫폼에서 사용 가능하다.
• HTTP 프로토콜의 표준을 최대한 활용하여 추가적인 장점을 같이 활용할 수 있다. (추가적인 장점에 대해 조사 필요)
• Hypermedia API(HTTP를 통해 HTML을 반환하는 API : 관련 링크)의 기본을 충실히 지키면서 범용성을 보장
• REST API의 명확한 메시지 전달
• 서버와 클라이언트의 분리

단점

• 표준이 존재하지 않아 정의가 필요하다.
• HTTP Method가 제한적이다.
• 구형 브라우저에서의 미지원 기능 이슈
• 브라우저를 통헤 테스트 할 경우 Header 값 수정의 전문성 필요

특징

• 균일한 인터페이스

• 무상태(Stateless)
  서버가 클라이언트의 모든 요청을 독립적으로 완료하는 통신 방법
  매번 서버가 요청을 완전히 독립적으로 이해해서 이행할 수 있음

• 계층화 시스템
  클라이언트와 서버 사이에 다른 중개자 연결 가능
  각 연결 과정에서 추가적인 로직이나 어플리케이션 개입가능

• 캐시 가능성
  서버 응답 시간을 개선하기 위해 클라이언트 또는 중개자에게 일부 응답을 저장하는 프로세스인 캐싱을 지원

• 온디맨드 코드
  서버에서 전송한 코드로 클라이언트 기능을 확장하거나 커스텀할 수 있음

REST API란

간단하게 말하자면 REST 기반으로 API를 구현한 것
REST API를 사용하여 구현한 웹 서비스를 'RESTful'하다고 할 수 있다.

특징

• 확장성
  정보를 유지할 필요가 없는 statless와 서버 클라이언트 연결을 줄일 수 있는 캐싱 등의 기능으로 선능을 저하시키는 통신 병목 현상을 방지하여 확장성을 지원
• 유연성
  클라이언트와 서버가 완전히 분리되어 각자의 기술 변경은 서로에게 영향을 주지 않아 유연하게 변화를 줄 수 있다.
• 독립성
  REST API는 사용되는 기술과 독립적이다. 다양한 프로그래밍 언어로 구성된 클라이언트나 서버 어플리케이션을 모두 작성할 수 있다.

REST API 설계 기본 규칙

도큐먼트 : 객체 인스턴스나 데이터베이스 레코드
컬렉션 : 서버에서 관리하는 디렉터리라는 리소스
스토어 : 클라이언트에서 관리하는 리소스 저장소

• URI는 자원을 표현(형식을 지정)해야 한다.
  동사(X) -> 명사(O)
  대문자(X) -> 소문자(O)
  도큐먼트의 이름은 단수 명사
  컬렉션과 스토어의 이름은 복수 명사

• HTTP Method로 자원의 행위를 표현한다.
  URI에 Method가 들어가면 안된다.
  CRUD 기능을 나타내는 동사표현을 쓰지 않는다.
  경로 부분중 변하는 부분은 유일한 값으로 대체한다.
  

• 슬래시'/'로 계층관계를 나타내며 URI의 마지막에는 포함하지 않는다.

• 하이픈'-'은 가독성을 높이기 위해(긴 URI일 경우) 사용한다.

• 파일 확장자는 URI에 포함하지 않는다.

코드 수정

위 공부한 내용을 토대로 REST하게 simple API를 수정하면..
전체 코드 Git-hub 링크

1. 유저 회원가입 엔드포인트
   POST Method, signup은 명사이므로 URI 문제 없음

if (method === 'POST') {
    if (url === '/users/signup') { ... }
...}  

2. 게시글 작성 엔드포인트
   POST Method, 기존 컬렉션 URI('/post') 를 복수형으로 변경해야 함

else if (url === '/posts') { ... }

3. 게시글 조회 엔드포인트
   GET Method, 기존 컬렉션 URI('/post/list') 를 게시글 작성된 URI('/post's) 로 변경

else if (method === 'GET') { /
      if(url === '/posts') { ... }
...}      

4. 게시글 수정 엔드포인트
   PATCH Method, 기존 컬렉션 URI('/post/list') 를 게시글 작성된 URI('/post's) 로 변경

else if (method === 'PATCH') { //4번 문제
      if(url.startsWith('/post/list') ) { ... }
...}