회고록

[Numble 챌린지 개발일지] 1주차 챌린지 시작 및 컨셉 기획

UL :) 2022. 10. 24. 23:32

2022-10-21 ~ 2022-12-01 총 6주 동안 진행한 Numble 나만의 지역 커뮤니티 만들기 챌린지에 참여하여 기록한 일지를 정리한 내용입니다.

 

 

넘블의 '나만의 지역기반 서비스' 연계 챌린지에 백엔드 포지션으로 참여하게 되었습니다 !

 

백엔드는 Spring/Spring Boot 기반, 프론트는 React Framework 기반으로 진행하는 프로젝트이며, 협업 경험을 쌓기 위해 신청했습니다.

 

디자이너 한 분과 프론트 현업자 두 분, 백엔드 현업자 한 분과 팀매칭이 이루어졌습니다. 현업자와 협업해보는 것은 처음이라 두근두근..ㅎ

 

 

 

총 6주동안 진행되며, 일정은 다음과 같습니다.

 

 

1주차에는 컨셉 기획 및 협업 방식을 정하기 위해 각자 조사를 해오기로 했습니다. 그런데... 😥

 

 

갑작스럽게 백엔드 현업자 분께서 개인 사정으로 불참하게 되어 팀 해체가 될 뻔했습니다... 😱

꼭 하고싶었던 프로젝트라 ㅠㅠ 발품팔아 지인인 백엔드 두 분을 모집한 후, 부랴부랴 회의를 재진행 했습니다.

 

주제에 대한 의견을 수렴한 결과, 소비자가 직접 모임을 개설하거나 참여할 수 있고, sns처럼 피드로 일상을 공유할 수 있는 형태의 서비스를 개발하기로 결정했습니다. 실제 서비스 중인 '문토'라는 어플을 참고했습니다.

 

다음 회의 때까지 상세기능을 기획한 내용을 각자 생각해오고 추합한 내용을 노션에 작성하기로 했습니다. 팀 노션 페이지 링크입니다 : https://www.notion.so/3-6a72f219e21443128c658dcbb7ee088e

 

 

그리고 REST-API를 구현할 거라, 그동안 개인적으로 메서드 및 상태코드 등을 조사 및 정리 해보았습니다.

 

REST API 특징

1.Uniform interface 통일되고 한정적인 인터페이스
2. tateless 무상태성 성격 (상태정보를 따로 저장하지 X) 들어오는 요청만 단순처리. -> 자유도 높고 구현단순해짐
3. Cacheable 캐시가능. HTTP 표준 Last-Modified 태그나 E-Tag를 이용하면 캐싱구현 가능
4. Self-descriptiveness(자체표현구조) API 메시지만 봐도 쉽게 이해 가능

5. Client-Server 구조 - 서로 의존성 줄음
6. 계층형 구조

REST API 설계

🚀 URI 예시

POST, GET, PUT, DELETE 4가지 메서드는 반드시 제공한다.

  • GET POST PUT DELETE /members
    • 보통 Collection에 PUT 요청은 지원하지 않으므로 405 ERROR 응답하기도 한다.
  • POST /login 로그인
  • POST /signup 회원가입

자원의 일부를 수정할 때는 PUT 대신 PATCH 사용하자. PUT은 모든 리소스를 수정할 때 사용하는 메서드로, 수정하지 않는 리소스까지 명세가 필요하다.

🛸 JSON 구조 주의할 점

  • 의미에 맞는 HTTP status를 리턴한다
    • API가 아닌 HTML 웹 프로젝트에서는 모든 응답을 200으로 처리하고 body내용으로 성공/실패를 판단하지만, API에서는 많이 이상한 구조이다. exception을 보내줘야한다!
  • HTTP status만으로 상태 에러를 나타낸다
    • http 상태 코드를 응답 객체에 중복으로 표시할 필요 없다.
  • Filtering
    • Collection(리스트)에 대한 GET 요청의 경우(GET /users) 리스트 검색 조건을 요청할 수 있다.
      • AND, OR
      • =, !=
      • >, >=
      • <, >=
      • IN(OR), NOT IN
      • LIKE(include)

HTTP 상태코드

  • 성공 응답은 2XX로 응답하고, 실패 응답은 4XX로 응답한다.
  • 201 Created 성공과 동시에 새로운 리소스가 생성. Content-Location에 리소스가 생성된 위치를 알려주면 좋다!
    • POST,PUT요청에 대한 응답에 주로 사용된다. (200을 보내줘도 되긴한데 이게 더 정확한 의미다)
    • 수정 요청으로 자원의 내용이 변경될 때도 사용
HTTP/1.1 201 Created
Content-Location: /users/1
{
    "id" : 1,
    "name" : "hak"
}
  • 202 Accepted 클라이언트의 요청은 정상적이나, 서버가 아직 요청을 완료하지 못했다.(작업 완료를 위한 일련의 작업들이 오래 걸리기 때문에 나중에 알려주겠다는 의미) 비동기 작업을 할 시 사용. 클라이언트가 요청 완료 여부를 확인할 수 있는 방법을 제공해야한다. Callback, Polling(HATEOAS, Content-Location 등으로 작업의 상태를 확인할 수 있는 URI 응답해야함) 두 가지 방법이 있다. 둘 다 제공하는 것이 좋다.
  • 204 No Content 클라이언트의 요청은 정상적이지만 컨텐츠를 제공하지 않는다. 204는 HTTP Response body가 아예 존재하지 않는 경우다. 사실 204를 응답하는 API는 흔하지 않다.
    • 보통 자원의 삭제 요청에 응답할 때 사용
    • 자원 수정 요청의 결과가 기존의 자원 내용과 동일하여 변경된 내용이 없을 때 204로 응답할 수 있다.
  • 400 Bad Request 클라이언트의 요청이 유효하지 않아 더 이상 작업을 진행하지 않는 경우
    • API 서버는 클라이언트 요청이 들어오면 사전에 검증을 통해 유효하지 않은 요청이면 400 상태 코드로 응답한다.
    • 그러나, 400 상태 코드로 응답하는 것만으로는 부족하다. 오류 발생 시 파라미터의 위치(path, query, body), 사용자 입력 값, 에러 이유를 꼭 명시하는 것이 좋다.
HTTP/1.1 400 Bad Request
{
    "errors": [
        {
        "location": "body",
        "param": "name",
        "code" : -765, //세부 에러 사항 표시
        "error": "TypeError",
        "msg" : "check your parameter"
        }
    ]
    "data": null
}
  • 401 Unauthorized 비인증, unauthenticated 즉, 인증이 안돼 자원을 이용할 수 없는 상태일 때 응답
  • 403 Forbidden 권한없음, unauthorized. 권한이 없는 자원에 접근할 때 응답하는 상태코드. 로그인이 필요
  • 404 Not Found 자원없음. 존재하지 않는 페이지
  • 405 Method Not Allowed 자원은 존재하지만 허용되지 않는 메소드일 때
  • 409 Conflict 클라이언트의 요청이 서버의 상태와 충돌이 발생한 경우
    • 400, 401, 403, 404, 405 상태 코드에 속하기 애매한 오류의 상황들을 409로 응답
    • 해당 요청의 처리 중 비지니스 로직상 불가능하거나 모순이 생긴 경우
    • 예를 들어 사용자의 게시물이 존재하는 경우 사용자를 삭제할 수 없다는 비지니스 로직이 있을 수 있다. 이렇게 API 사용에 있어 비지니스 로직상 모순이 발생하여 처리가 불가능한 경우 응답하는 상태 코드다.
  • 429 Too Many Requests 비정상적인 방법, DoS나 Brute-force attack으로 공격 시.. 이러한 경우 일정시간 뒤 요청할 것을 나타내는 응답. HTTP hearder Retry-After을 이용
HTTP/1.1 429 Too Many Requests
Retry-After: 3600

3600초 후에 요청 가능

  • 5XX 에러는 절대 사용자에게 나타내지 않는다. 이건 서비스 장애다.

주로 사용되는 것들을 위주로 정리했으며, 더 다양한 코드는 다음 링크를 참고하면 좋을 듯하다!

https://hi098123.tistory.com/200

참고한 글

https://sanghaklee.tistory.com/57

https://sanghaklee.tistory.com/61?category=790214

참고하면 좋은 글!!

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

저작자표시 비영리 변경금지