[node js] 4주차 -1

Fake API란?

• 1. Fake API가 뭘까?
  • Fake API는 주로 API가 아직 만들어지지 않았거나 실제 서버를 실행하기 어려운 경우에 실제 API가 아닌 가짜 API를 만들어서 프론트엔드나 서버의 개발 또는 테스트를 원활하게 진행할 수 있게 도와줍니다.
  • 아래의 인터페이스 예시를 살펴보면서 조금 더 알아보겠습니다.
  1. JSON Placeholder
  • JSON Placeholder의 페이지를 보시면 아래와 같이 예시가 있습니다.

• // Fake API
  fetch('<https://jsonplaceholder.typicode.com/todos/1>')
    .then(response => response.json())
    .then(json => console.log(json))
  
  // Output
  {
  	"userId": 1,
  	"id": 1,
  	"title": "delectus aut autem",
  	"completed": false
  }
  

  • Fake API 코드를 보시면 fetch라는 키워드 안에 주소가 보이시죠? 이는 이 주소로 API Request를 요청했을때 결과값을 첫번째 then 키워드에서 response를 json 형태로 가져와 마지막으로 json 데이터를 console.log로 리턴 해준다는것을 의미합니다.
  1. Fake Store API
  • Fake Store API는 JSON Placeholder의 사용법이 거의 동일합니다. 하지만 Fake Store API는 쇼핑 웹사이트와 같은 웹서비스에서 필요한 Fake API를 제공합니다.

• // Fake API
  fetch('<https://fakestoreapi.com/products/1>')
              .then((res) => res.json())
              .then((json) => console.log(json))
  
  // Output
  {
    "id": 1,
    "title": "Fjallraven - Foldsack No. 1 Backpack, Fits 15 Laptops",
    "price": 109.95,
    "description": "Your perfect pack for everyday use and walks in the forest. Stash your laptop (up to 15 inches) in the padded sleeve, your everyday",
    "category": "men's clothing",
    "image": "<https://fakestoreapi.com/img/81fPKd-2AYL._AC_SL1500_.jpg>",
    "rating": {
      "rate": 3.9,
      "count": 120
    }
  }
  ​

  
  
  • 이전과 마찬가지로 fetch와 then을 통해서 Request와 Response가 이루어지는것을 볼 수 있습니다.
  • Rest API naming rule
  1. 마무리
  • 다른 API를 많이 살펴봤는데요, 사람이 이해하기 쉬운 API에 대해 감이 잡히셨나요? 그리고 인터페이스에 대해 이해가 되셨길 바랍니다.
  • Fake API는 보통 프론트엔드에서 API가 없는 상태에서 사용하는게 일반적이지만, 우리는 이것을 보며 API를 어떻게 설계해야 하는지 살펴보았습니다.
  • 인터페이스가 동일하다면 Fake API를 사용하던 서비스도 언제든 여러분이 만든 API를 사용할 수도 있는거예요! 이런 상황을 직접 맞이하게 된다면 인터페이스가 얼마나 중요한지 실감이 되실겁니다 😎

블로그 API 구상하기

• 1. 블로그엔 어떤 기능이 필요할까?
  • 기능 분석을 먼저 해야 어떤 API가 필요할지 구상할 수 있어요!
  • 여러분에게 익숙한 블로그라는 서비스는 기본적으로 어떤 기능이 필요할지 한번 고민해봐요!
    • 물론 기획이나, 서비스 특성에 따라 다를수 있지만 아주 일반적인 네이버 블로그같은 형식을 생각해봅시다!
    • 어떤 기능이 존재해야 할지 항목을 하나 하나 적으며 생각해보세요! ex) 게시글 작성, 게시글 삭제, ...
  • 고민 한 후 열어보세요!!
  • 이번엔 수업 진행을 위해 제가 정해드릴거예요! 여러분이 고민했던 기능이 모두 포함되어 있다면 성공적이예요! 
    • 회원 가입
    • 로그인
    • 회원 정보 수정
    • 회원 탈퇴
    • 게시글 작성
    • 게시글 목록 조회
    • 게시글 상세 조회
    • 게시글 수정
    • 게시글 삭제
    • 특정 게시글에 댓글 작성
    • 특정 게시글에 달린 댓글 목록 조회
    • 특정 게시글에 달린 댓글 수정
    • 특정 게시글에 달린 댓글 삭제
  • 각 기능에 대한 API 구상
• 이제 구현하기로 마음 먹은 기능들의 API를 어떤 HTTP Method로 작성할지, 주소는 어떻게 할지 고민하며 작성해보세요.
• 작성하는 양식은 아래와 같습니다. 데이터 표현식은 jsdoc을 따릅니다. 
  • 기본적인 요청/응답 인터페이스 예시
  • Request 
    • Method: GET
    • URL: /articles
    Response
    • HTTP Status Code: 200
    • Payload:
    •  
    • { articleId: number, content: string, authorId: number }[]
  • Body를 가진 (POST, PUT, DELETE, ... 등의 Method)를 가진 인터페이스 예시
  • Request 
    • Method: POST
    • URL: /articles
    • Body:

    • { content: string, authorId: number }
      

    Response
    • HTTP Status Code: 201
    • Payload:

    • { articleId: number }
      

  • URL에 Params가 있는 API 예시
  • Request 
    • Method: PUT
    • URL: /articles/:articleId
    • Body:

    • { content: string }
      

    Response
    • HTTP Status Code: 200
    • Payload:

    • { articleId: number, content: string, authorId: number }
      

• 1. 마무리
  • 리소스를 어떻게 정의해야 하는지 감이 잡히셨나요? 여러분 스스로 체감이 안되실지도 모르지만, 성실하게 잘 따라오셨다면 이전보다 인터페이스를 작성하는 일에 훨씬 익숙해지셨을거에요.
  • 인터페이스에 대한 고민을 하지 않은 채 바로 코드를 작성하기 시작했다면 서버에 버그를 발견 했을때 프론트엔드까지 수정해야 하는 일이 생길 수 있답니다! 하지만 반대로 인터페이스를 제대로 정의하고 코드를 작성했다면 기능에 버그가 있어도 서버의 코드만 슬쩍 수정하면 됩니다.