23_12_22 TIL

오늘 배운 것 

 

REST API 

REST(REpresentational State Transfer) 

상태의 전이(State Transfer)를 표한하기 위한 HTTP상의 아키텍쳐 스타일

State는 Resource의 State를 표현하며 Resource는 파일 문서 데이터 등을 모두 포함한다

Resource는 Domain Model에 대한 데이터 이기 때문에 Resource는 Domain Model이라고 봐도 된다
//

URI(Resource)- URL을 통해 Resource 이름을 표현한다

Method(Verb) HTTP의 Method 를 사용해 상태를 변경하는행위(Verb)를 표현한다 

HTTP Method는 GET , POST, PUT,PATCH,DELETE,OPTIONS로 구성된다

GET:Read의 요청 Resource의 정보를 획득하기 위해 사용한다

POST:Create 요청 새로운 Resource의 정보를 획득하기 위해 사용한다

PUT: Update요청 Resource에 대한 정보를 수정하기 위해 사용한다 수정되는 정보를 포함한 모든 Resource의 정보를 포함하여 요청한다

PATCH: Update요청 Resource의 대한 정보를 수정하기 위해 사용 수정되는 정보만 요청 

DELETE: Delete요청 Resource를 삭제 하기위해 사용한다

OPTIONS: 서버와 클라이언트 사이의 통신 옵션을 확인 하기 위해 사용한다
 
REST에서 표현을 위해 사용하지 않고 HTTP에서 보안 및 효율성을 위해 자동적으로 생성되는 요청

JSON / XML 등(Representation of Resource)
리소스의 상태를 표현하는 방법

REST Style 디자인 가이드 

URL(Resource)은 이름은 명사 , 소문자, 복수형 사용권장 동사로 사용 지양 ex)/ /getPosts x , posts o  

/를 통해 리소스관의 계층관계를 표현 ex) /posts/{id}/comments

URL 마지막에 / 를 포함하지 않는다  ex)  /posts/

밑줄 (_)은 사용하지 않아야 하고 하이픈(-)을 사용한다 ex) /posts/{id}/long-comments

특정 리소스 하나를 가져올때는 URL에 해당 리소스의 Identifier를 포함하여 표현한다 ex) /posts/{id}

리소스 목록의 페이징 필터링 정렬 검색을 통해 정보를 가져올시 Path Variable를 활용한다 ex) /posts? page=12 , /posts? order=latest

적절한 Status Code를 응답한다

-상태 코드의 분류-

1XX(Informational) 정보 제공

임시응답 , 요청이 수신되었으며 프로세스가 계속 진행 중임을 알림

2XX(Successful) 성공

요청이 성공적으로 처리되었음을 나타냄

3XX(Redirection) 리다이렉션

클라이언트가 요청한 리소스의 위치가 변경되었음을 나타낸다

4XX ( Client Error) 클라이언트 오류

클라이언트의 요청에 오류가 있음을 나타낸다

5XX (Server Error) 서버오류

서버에서 요청을 처리 중에 문제가 발생한 경우 서버부하, DB관련 오류 등 클라이언트에 의한 오류가 아닌 서버의 장애로 발생할 때 사용

자주 쓰는 상태코드

- 200 : OK
- 201 : Created, 리소스가 정상적으로 생성 되었을 알림
- 204: No Content, 리소스가 삭제 되었음을 알림
- 400 : Invalid Request, 요청이 잘못됨을 알림
- 401 : Unauthorized, 클라이언트가 인증되지 않았거나, 인증정보가 부족함을 알림
- 403: Forbidden, 서버가 요청을 이해하긴 했으나, 권한이 없음을 알림
- 404 : Not Found, 리소스를 찾을 수 없음
- 500 : Internal Server Error, 서버의 내부 에러
- 501 : Not Implemented, 요청한 URI의 메서드에 대해 서버가 구현하고 있지 않음을 알림
- 502: Bad Gateway, 게이트웨이 역할을 하는 서버가 뒷단의 서버로부터 잘못된 응답을 받았음을 알림

글과 댓글 조회, 수정 , 삭제하는 예시 

- 글 목록의 조회: GET/posts
- 단일 글 조회:GET/posts/{id}
- 글 생성: POST/posts
- 글 수정: PUT /posts/{id}
- 글 삭제: DELETE /posts/{id}
- 특정 글의 댓글 목록 조회: `GET /posts/{id}/comments
- 특정 글에 댓글 추가 : POST /posts/{id}/comments
- 특정 글의 댓글 수정: PUT /posts/{id}/comments/{id}
- 특정 글의 댓글 삭제: DELETE /posts/{id}/comments/{id}


REST API 와 RESTful API의 다른 점

RESTful은 REST의 규칙을 잘 지킨다는 의미 

성숙도 모델 (Maturity Model)

level 0 : The Swamp of POX 
소수의 URL을 갖고 있고 일반적으로 POST 만 사용하는 스타일 RPC(Remote Procedure Call)과 유사

level 1 : Resource 
위에 설명한 REST와 유사하게 URL을 통해 Resource를 표현.  Verb(HTTP Mothod)를 POST만 주로 사용

level 2 : HTTP Verbs
Resource를 URL로 사용하면서 HTTP Method를 통해 행위(Verb)에 대해서 표현하고 있습니다

level3: Hypermedia Controls 
level 2에 더하여 HATEOS(Hypertext As The Engine Of Application)를 잘 지키는 단계 
클라이언트에게 응답을 할 시 다음 단계로 할 수 있는 작업에 대해 알려주기도 한다
Resource에 대한 데이터만 응답하는 게 아니라 클라이언트의 다음 작업을 위한 URL도 함께 알려준다 (댓글을 조회할 시 댓글에 좋아요을 달거나 대댓글을 달 수 있는 API URL이 뭔지 함께 알려주는 것 ) 

level 3 까지를 준수할 때 RESTful 하다고 한다 

level 3을 준수하여 개발할 시 클라이언트는 각 요청을 위한 URL을 몰라도 되고 응답만으로 다음 행위를 어떻게 할지를 판단할 수 있다 하지만 이것을 위한 개발기간이 늘어나고 Swagger, Postman과 같이 API Document를 정리해 주는 도구들이 많이 등장하면서 프론트에서 요청을 위한 URL을 하드 코등하는 것이 추세이다

빠른 개발생산성을 위해 LEVEL 2까지 준수한다 

 

특강 내용 

 

알고리즘을 풀 때 시간복잡도를 생각하여 문제를 해결하려고 해야 한다 

 

코틀린의 자료구조를 자세히 알아야 좀 더 효율적으로 문제를 풀 수 있기 때문에 공부할 것 

 

//

특강을 듣고 나서 같은 팀 멘토? 같은 분에게 실력향상과 효율에 대해 질문을 했는데 현재 나는 알고리즘을 주먹구구식으로 해결하는데 초점을 두고 문제를 하루에 하나에서 이틀에 하나 정도 해결하는 중이다

 

문제풀이를 보면 빠르게 답을 얻고 넘어갈 수 있지만 내가 스킬을 얻지 못한다고 생각해서 일단은 막 풀어 보는 중인데 문제 풀이는 내장함수로 띡띡 숏코드로 해결하는 답안이 거의 전부이다 

 

코틀린은 유난히 내장함수가 많고 이런 것도 있나 싶은 것도 존재하는 거 같다

 

근데 이걸로 문제를 풀면 답안을 커닝하는 느낌이 들어 이걸로 정말 긴가민가 했었는데 팀원 분이 어차피 꼭 써야 하는 거나 자주 쓰는 거라면 외우게 되고 내가 돌아가는 메커니즘을 알고 있다면 그렇게 해도 된다고 해서 앞으로는 알고리즘의 풀이를 바꿔볼 생각이다

 

무식하게 코드를 짠다고 해서 크게 실력이 나아지는 것도 아니고 자주 쓰는 내장함수를 외우는 게 더 득이 될 거 같다는 생각을 하였다