16~17일 한일
- RESTful API 공부
- 좋은 자료
- REST API 중심 규칙
```- URI는 정보의 자원을 표현해야 한다. (리소스명은 동사보다는 명사를 사용) ex) GET /members/1
- 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현 ex) DELETE /members/1 ```
-
더 많은 내용들이 있지만 바로 신경쓸수 있는 부분들
- HTTP 응답 코드의 사용
```
- 200 반환 코드를 사용하여 에러 응답을 포함하는 방식과 달리 명시적으로 에러 응답을 사용 ```
- URI 설계시 주의할 점
```- 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용
- URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
- 하이픈(-)은 URI 가독성을 높이는데 사용
- 밑줄(_)은 URI에 사용하지 않는다.
- URI 경로에는 소문자가 적합하다.
- 파일 확장자는 URI에 포함시키지 않는다.
```
- HTTP 응답 코드의 사용
```
- 프레임워크, 라이브러리
- 의외로 간단하다
프레임워크 : 프레임워크 코드가 내 코드를 호출 라이브러리 : 내 코드가 라이브러리를 호출
- 추가 사항 (출처)
프레임워크도 제어의 역전 개념이 적용된 대표적인 기술이다. 프레임워크는 라이브러리의 다른 이름이 아니다. 프레임워크는 단지 미리 만들어 둔 반제품이나, 확장해서 사용할 수 있도록 준비된 추상 라이브러리의 집합이 아니다. 프레임워크가 어떤 것인지 이해하려면 라이브러리와 프레임워크가 어떻게 다른지 알아야 한다. 라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어한다. 단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐이다. 반면에 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다. 보통 프레임워크 위에 개발한 클래스를 등록해두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만드는 방식이다. 최근에는 툴킨, 엔진, 라이브러리 등도 유행을 따라서 무작정 프레임워크라고 부르기도 하는데 이는 잘못된 것이다. 프레임워크에는 분명한 제어의 역전 개념이 적용되어 있어야 한다. 애플리케이션 코드는 프레임워크가 짜놓은 틀에서 수동적으로 동작해야 한다. [원문] 토비의 스프링3 p.95 (1장.오브젝트와 의존관계)
즉, 주도권 혹은 제어권이 누구한테 있냐에따라 프레임워크, 라이브러리가 구분 될 수 있다.
16~17일 느낀점
- 자료들을 찾다보면 RESTful과 REST API란 용어가 등장을 하는데 둘의 차이가 무엇일지 궁금해서 찾아봤다. 직접적으로 해답을 찾진 못했지만
오늘날 스스로 REST API라고 하는 API들의 대부분이 REST 아키텍쳐 스타일을 따르지 않는다.
이와 관련된 자료들도 찾다보니 REST API가 아닌 것들을 몇몇 이유때문에 REST API라고 불리던데(해당 내용) REST API가 아닌 REST API와 진짜 REST API를 구분하기 위해서 생긴 용어가 아닐까 싶다.
-
라이브러리에 대해서는 “남들이 미리 만들어놓은 함수들을 가져다 쓸수 있는 것” 이라는 정도의 지식을 가지고 있었는데 화이트과정에서 자바 백엔드는 스프링 프레임워크를 사용 한다는데 스프링이야 프레임워크의 이름일테고 그래서 프레임워크가 무엇인지 궁금했었다. 당시 찾아 봤을땐 제대로 이해가 안돼서 이용하게 되면서 종속성이 발생하면 프레임워크 아니면 라이브러리 이정도로 이해를 하였다. 그러다 오늘 다시 찾아봤는데 위의 두 사진만으로도 다른 말을 추가 할 필요가 없을 것 같다.
-
사실 프레임워크와 라이브러리에 대해 찾아본 이유는 백엔드 내부 발표로 osi 7계층을 활용하여 네트워크에 대해서 발표 하려다가 여러 어려움으로 다른 주제로 할만한게 무엇이 있을까 고민하다가 내가 이전에 궁금해하다가 제대로 해결 못했던 프레임워크와 라이브러리가 어떻게 다를까가 기억나서 찾아봤다.
일단 발표 준비까진 안하고 스스로 학습차원으로 자료들을 많이 찾아봤는데 생각보다 어려울것 없는 내용인 것 같아 발표를 할 정도의 주제인가 의문점도 들고, 의외로 다들 구분을 할 줄 알거나 다른 사람들한테도 도움이 될 만한 주제인지가 살짝 고민된다. - 네트워크를 발표 주제로 하기 쉽지 않은 이유가 사실 일단 내용 자체가 어려워서 추가적인 공부가 꽤나 필요하다.(설명을 못 한다는건 아직 제대로 아는게 아니란거라던데…) 어떤 파트를 얼마나 다뤄야 할지나 다른 사람들의 기본지식이 얼마나 있냐에 따라 단어 선택이나 부연 설명의 필요 유무(예를 들면 mac address가 뭔지는 몰라도 단어자체는 들어봤는가 아닌가)가 갈린다. 그래서 일단은 쉽게 가보자 싶어서 내가 이전에 궁금했던 주제를 알아봤다.
내일 할일
-
JSON API 및 AJAX 실습 피드백 발생시 해결
-
MVC 구현 및 Spring 기본 실습 시작(JSON API 및 AJAX 실습이 merge 된다면)
- 첫번째 요구 사항들 파악
- 실습 시작