5일차. 첫주가 마무리 되었습니다.
오늘은 프로젝트를 완성하고 발표하는 날.
다른 조의 프로젝트도 볼 수 있다.
발표를 들으며 프로젝트를 회고하며 얻은(?) 개념이라해야할까 방식(?)을 정리해보자.
RESTful API
'개발을 진행하면서 Restful하게 API를 작성했는지'가 발표 내용에 포함되어 있었다. 여기서 RESTful을 처음 접하게 되었는데 검색하다 이게 뭔소린가 이해가 안되서 일단 넘어갔다.
근데 발표시간에 튜터님이 다시 언급하셔서 한 번 열심히 찾아서 이해해보려고 한다. 이해가 될 지는 모르겠어요..
RESTful API란?
aws에서는
RESTful API는 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스입니다.
RESTful API는 안전하고 신뢰할 수 있으며 효율적인 소프트웨어 통신 표준을 따르므로 이러한 정보 교환을 지원합니다.
라고 설명한다. 어렵다.
api(application programing interface)는 앞선 TIL에서 언급했듯이 은행 창구의 느낌으로 클라이언트와 서버(리소스를 제공하는 시스템)이라고 이해했는데 RESTful이 무엇일까.
위 내용은 일단 입력하고 이해는 좀 걸릴 것 같다. 그럼
REST란?
Representational State Transfer(REST)는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처입니다.REST는 처음에 인터넷과 같은 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어졌습니다. REST 기반 아키텍처를 사용하여 대규모의 고성능 통신을 안정적으로 지원할 수 있습니다. 쉽게 구현하고 수정할 수 있어 모든 API 시스템을 파악하고 여러 플랫폼에서 사용할 수 있습니다. (aws)
영어 그대로 풀이를 하면 대표하는(?) 특정 표현된(?) 상태를 옮기는 것이라는데
- '자원(resource)의 대표(representation)에 의한 상태 전달' 이라고 이해하면 될 것 같아
- 여기서 자원은 api에서도 나온 리소스로 문서가 될 수도 이미지가 될 수도 있다.
- 자원의 대표란 그 자원을 대표하기 위한 특정이름 이라고 한다.
- 상태전달은 데이터를 요청하고 그 자원을 상태를 전달하는 것.
자원을 이름으로 구분하고 해당 자원의 상태를 주고 받는 모든 것이 REST라고 할 수 있지만, 일반적으로 REST라고 하면 좁은 의미로 HTTP를 통해 CRUD를 실행하는 API를 뜻합니다.
- RESTful은 REST의 비공식적 구현 가이드입니다
- HTTP 프로토콜을 이용하기 때문에 URL(route)를 통해 자원을 특정짓고 HTTP Verbs를 통해 할일(CRUD)을 지정합니다. 또한 JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적입니다.
정리하자면, 강의에서 배운 기능을 서버와 클라이언트에서 주고받으며 코드를 적었던 것들이 REST한 API였던 것이다. 강의를 따라 코드를 적고 있었는데 그게 REST란걸 이제 알았네..ㅎ
그럼 CRUD란?
회고 시에도 튜터님이 CRUD를 말씀하셨고 REST를 알아보면서도 나왔다.CRUD는 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말이다. (위키백과)
REST 아키텍처 원칙
- 균일한 인터페이스
- 서버---리소스(균일한 식별자, 충분한 정보, 명확한데이터..)--->클라이언트
- 일관적인 인터페이스로 분리되어야 한다.
- 무상태(Stateless) : 서버는 모든 요청을 개별적으로 처리.
- 계층화(Layered System): 특정 역할에 따라 계층을 나눠서 관리
클라이언트 요청을 이행하기 위해 함께 작동하는 보안, 애플리케이션 및 비즈니스 로직과 같은 여러 계층으로 여러 서버에서 실행되도록 RESTful 웹 서비스를 설계할 수 있습니다.
- 캐시 처리 가능(Cacheable)
- Code on demand (optional)
- 클라이언트-서버 구조
URL Rules
- 마지막에 / 포함하지 않는다.
- _(underbar) 대신 -(dash)를 사용한다.
- 소문자를 사용한다.
- 행위(method)는 URL에 포함하지 않는다.
- 컨트롤 자원을 의미하는 URL 예외적으로 동사를 허용한다.
우리 조에서 구현한 api 
- URI 작성법이 틀렸다. _대신 -를 사용하고 대문자는 사용하지 않는걸로~!
완벽히는 아니지만 조금은 이해한 것 같다.
KPT 회고?
Keep, Problem, Try 세 가지로 분류해서 프로젝트를 분석하고 회고를 진행하는 방법이다.
Keep: 현재 만족하고 있어 계속 유지해도 좋은 부분Problem: 문제점. 개선이 필요한 부분 + 해결방안까지Try: 다음 프로젝트를 위해 노력해야하는 부분
마무리
개인적인 프로젝트 회고를 하자면
조금 더 기능적인 면에 욕심을 가져도 괜찮았을 거란 생각이 든다.
처음하는 협업이라 (그것도 온라인으로 진행하는 팀플) 익숙하지 않아서 의견 제시를 할 때 미숙한 면이 있던 것 같다.
다양한 기능을 생각하고 구현하려는 노력이 필요하다. 일단 지르는 것도 능력이라고 생각함.
지레 겁먹고 발 빼는 것보단
다음 프로젝트에선 조금 더 열심히 해보자~!
