[TIL 2023.05.19] 팀소개 프로젝트 마무리&발표

💻오늘 배운 내용

RESTful API?

---

REST(Representational State Transfer)의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미합니다.

1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
2. HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.

 

CRUD Operation이란

Create : 데이터 생성(POST)

Read : 데이터 조회(GET)

Update : 데이터 수정(PUT, PATCH)

Delete : 데이터 삭제(DELETE)

 

REST 구성 요소

REST는 다음과 같은 3가지로 구성이 되어있다.

1. 자원(Resource) : HTTP URI
2. 자원에 대한 행위(Verb) : HTTP Method
3. 자원에 대한 행위의 내용 (Representations) : HTTP Message Pay Load

 

REST의 특징

1. Server-Client(서버-클라이언트 구조)
2. Stateless(무상태)
3. Cacheable(캐시 처리 가능)
4. Layered System(계층화)
5. Uniform Interface(인터페이스 일관성)

 

REST의 장단점

장점

• HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
• HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 준다.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
• Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
• 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
• 서버와 클라이언트의 역할을 명확하게 분리한다.

단점

• 표준이 자체가 존재하지 않아 정의가 필요하다.
• HTTP Method 형태가 제한적이다.
• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.
• 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.(익스폴로어)

 

REST API 설계 예시

1. URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다.

Bad Example http://khj93.com/Running/
Good Example  http://khj93.com/run/

 

2. 마지막에 슬래시 (/)를 포함하지 않는다.

Bad Example http://khj93.com/test/
Good Example  http://khj93.com/test

 

3. 언더바 대신 하이폰을 사용한다.

Bad Example http://khj93.com/test_blog
Good Example  http://khj93.com/test-blog

 

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

Bad Example http://khj93.com/photo.jpg
Good Example  http://khj93.com/photo

 

5. 행위를 포함하지 않는다.

Bad Example http://khj93.com/delete-post/1
Good Example  http://khj93.com/post/1

 

⁂ RESTFUL이란 REST의 원리를 따르는 시스템을 의미

하지만 REST를 사용했다 하여 모두가 RESTful 한 것은 아니다.  REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있으며 모든 CRUD 기능을 POST로 처리 하는 API 혹은 URI 규칙을 올바르게 지키지 않은 API는 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용하였지만 RESTful 하지 못한 시스템이라고 할 수 있다.

 

❗프로젝트 발표

README 작성

프로젝트 깃헙 주소를 제출하라는데 그래도 제출물인데 그냥 파일만 덩그러니 업로드 되어있는 것이 보기에 좋지 않아서 리드미 파일도 같이 작성했다.

그런데 그냥 타이핑으로 치는게 아니더라…

 

폰트크기 조절은 노션과 같다

###은 큰제목

##/#으로 갈수록 사이즈가 작아진다

 

표는 | ------ | 형태로 구현한다

이런식으로 작성

목차를 쓸때 항목을 선택하면 그위치로 이동하게 하고 싶다면

이렇게 작성하면 된다

이미지도 넣고 싶었는데

깃허브에 이슈창을 이용하여 이미지를 업로드하면 저러한 코드를 생성해준다 그걸 복붙해서 가져왔다

깃헙은 나보다 똑똑하구나…ㄷㄷ

 

이렇게 완성된 우리팀 리드미! 아무도 시키지 않았지만 괜히 해놓고 뿌듯하다.

저렇게 해두면 누가 와서 보더라도

‘아, 팀프로젝트구나, 5명이네, 어떤걸 만들었네, API는 저렇게 구성했구나’

하고 알 수 있지 않을까.

저지르고 나서 팀원들한테 리드미 만들었다고 하니 다들 괜찮다고 해줘서 뿌듯2했다.

 

💡발표이후

발표 후 팀끼리 프로젝트 KPT를 진행했다

Keep

• 서로 질문하고, 격려하고, 적극적으로 피드백 하려고 한 것
• 오류가 나는 상황을 바로바로 공유하는 것
• 기능 별로 브랜치를 나누고 작업하기
• 미숙한 부분을 팀원이 도와주는 것
• 질문에 성실하게 응답하며 해결될 때까지 도와주는 자세
• 이슈가 생기면 같이 해결하려고 노력함

 

Problem

1) 문제

• github 사용 방법 미숙
• 변수를 미리 정하지 않아 통일되지 않았던 부분
• 프로젝트 구조를 잡지 않아 브랜치 병합 시 어려웠음
• 하루하루 무엇을 했는지 자세한 기록이 없다.
• 초반에 정한 우리팀의 규칙대로 진행하지 않았다. (개인 작업 보고, 진행상황 공유 등)

2) 원인

• 경험 부족
• 커뮤니케이션 부족

 

Try

• github에 대해서 공부하기
• 하루를 끝내면서 본인이 진행한 정도를 팀원과 공유하기
• 기획 단계에서 변수 명부터 스타일 사용을 위한 아이디나 클래스 값, 주요 색상 통일하기
• 매일 하루 마무리에 각자의 결과물을 merge하며 바로바로 업데이트
• 팀원의 질문에 즉각적으로 반응할 것
• 매일 하루 시작에 중간목표를 세워두면 효율적으로 작업할 수 있을 것 같다.

 

느낀점

• 괴코딩 - “서버 만드신분의 결과를 보고 내가 진짜 많이 부족하다고 느낌. 앞으로 가야할 길이 멀지만 포기하지 않고 최선을 다해야겠다.”

다른팀원들분도 한줄씩 쓰셨지만 여기선 생략

 

🧐궁금점과 부족한 내용

오늘 다른팀 발표와 튜터님 피드백을 들으면서 생소한 단어들이 우루루 쏟아져 나왔다

• 동기/비동기 방식?
• 클린아키텍쳐
• 원사이즈 웹사이트 드롭다운?
• 웹 인터렉션
• css display/position/midia query

마침 내일 주말이니 공부해보자

 

📋레퍼런스

https://khj93.tistory.com/entry/네트워크-REST-API란-REST-RESTful이란https://www.freecodecamp.org/korean/news/gisheobeu-peurojegteue-rideumi-paileul-jal-jagseonghaneun-bangbeob/