내배캠 12/1 TIL

REST API 에 관해

- API 는 뭐 이미 지겹도록 얘기를 들었고 요즘은 굳이 IT쪽인력이 아니더라도

알 법할 정도로 생활속에 깊숙히 들어와있다.

간단히 말하면, API는 돈이 된다! (실제로 아마존 웹사이트 크롤링을 시도하려하면

돈내고 API 사서 쓰라는 경고창이 뜨더라...)

- 이렇게 중요한 API를 어떻게 최대한 효율적이고 친절하게 작성할까 하는 고민에서 나온게

RESTful API 작성이다. 쪼금 더 자세히 말하면, 기존의 웹, HTTP 관련 기술을 최대한 활용하여 (왜냐하면

기존에 널리 퍼져있기 때문에 최대한 표준화를 시도한 것) 누구나 알아볼수 있게 하자는 일종의

규칙이다.

사실 API가 뭔지 몰라도 우리가 웹사이트, 특히 쇼핑 사이트를 탐험하다보면 슬래시(/)로

카테고리나 상품 ID를 구분한다 ( microwave / 1234333 식으로...)

- 내가 이해한 바로는

1. 웹과 HTTP 기술만 따르면 어떤 브라우저나 플랫폼에서도 사용하게 하자

2. Stateless, 즉 각 요청이 state(상태)가 없는, 독립적인 요청으로 서버에서 처리해야함

3. 캐시가 가능! 즉 기존 인프라를 재사용해 불필요한 리소스 낭비를 막자

4. 자체적인 표현기능, 즉 API 메시지 등에 충분한 표현을 담자는 뜻.

이다.

- 또 다른 강사님은 대표적 예로 유튜브 API와 깃허브 API가 사실상 RESTful API 의 정석이라고 하셨는데,

다만 하나 아쉬운건 유튜브 API에는 다른 기능과 관련한 링크가 없어 아쉽다고 하시더라. 근데 더 대단한건 깃허브는 관련 기능 링크를 수십개를 모두 탑재하고 있더라.... 대단하다고 느꼈다.

- 그리고 그동한 궁금했던 Graph ql 에 관련해 짤막하게 정보를 얻었는데, 쉽게 말하면 API로 불러오는 자료들을 좀 더 세밀하게 가져올수 있는 도구라고 보면 되겠다.

- HTML의 시멘틱 태그의 중요성을 강조!

사실 안써도 되고 Div로 떡칠해도 큰 문제는 없지만, 성능이나, 구조화 등을 고려할때

최대한 시멘틱하게 HTML을 구성하라고 하시더라.

- 그 외 CSS나 JS, 그리고 MySQL 등은 가칭 Spartagram을 클론코딩 해보면서

더 뜯어볼 생각이다.

- 사실 유데미에서 옛날에 끊어놓은걸로 더 진도를 나가고 있는데 다행인건 MY SQL과 사실

구현방식이나 사소한 문법이 다를 뿐, 거의 똑같다고 하셔서 앞으로도 쭉 같이 병행할 예정이다

- Foreign key에 대해 다시 조금 곱씹어봤고, Delete시 옵션을 주는 방법 (NULL 로 하거나 Cascade로

둘다 삭제해버리던가) 등을 배웠다.

- 그런데 Join 부분에서 살짝 막혔다. 이 부분은 몇번이고 다시 보면서 눈에 익힐 생각이다.