TIL | WEB / HTTP STATUS CODE / Software Architecture and Design

올해 연말이나 내년 초에 지원할 웹 백엔드 포지션을 대비하여, 기술 인터뷰에서 지원자가 기본적으로 알고 있다고 가정(?)하고 있는 것들을 먼저 정리해보려고 합니다. 가장 기초적이지만, 정확한 워딩으로 풀어낼 수 없던 것들을 정리할 것입니다. 이와 관련된 개념은 크게 Web 기본 개념, HTTP status Code, Software Architecture and Design입니다. 오류(?)가 있을 수 있으니, 댓글에 남겨주시면 감사드리겠습니다.

1. Web 개념

Web이란

웹 개념은 다음과 같습니다.

• W3 ; 인터넷에 연결된 사용자들이 서로의 정보를 공유할 수 있는 공간을 의미한다. 인터넷 상에서 텍스트나 그림, 소리, 영상 등과 같은 멀티미디어 정보를 하이퍼텍스트 방식으로 연결하여 제공한다.

2. HTTP status code

HTTP는 HTML과 같은 하이퍼미디어 문서를 전송하기 위한 앱 레이어 프로토콜입니다. HTTP의 특징은 무상태 프로토콜이기 때문에 클라이언트의 요청에 응답을 주는 단발성 요청/응답이 이루어집니다. 따라서 클라이언트의 요청에 따라 서버에서는 그에 따른 액션을 반환해주어야 하는데, 이때 쓰이는 것이 HTTP status code입니다. HTTP status code는 포스팅에 담은 개수보다 훨씬 더 많이 존재합니다. 이와 관련하여 공부해서 점차 더 쌓아가기로 하고, 공부한 코드를 중심으로 정리해보겠습니다.

2XX : Successful responses

• 200 : OK ; 요청 성공. 본 요청에 응답을 정보로 반환함.
• 201 : 201 Created ; 생성에 대한 성공 응답.
• 204 : No Content ; 요청은 성공. 하지만 요청에 대해서 보내줄 수 있는 콘텐츠가 없음을 의미한다. 204 응답은 캐시에 저장할 수 있다.

3XX : Redirection messages

• 302 : Found ; 요청한 리소스의 URI가 일시적으로 변경되었음을 의미한다.

4XX : Client error responses

• 400 : Bad Request ; 잘못된 문법으로 서버에 요청하여 서버가 요청을 이해할 수 없음을 의미한다.

5XX : Server error responses

• 500 : Internal server error ; 웹 사이트 서버에 문제가 있음을 의미하는데, 서버가 그 문제에 대해 더 구체적으로 설명할 수 없음을 의미하는 응답이다.
• 504 : Gateway Timeout ; 웹페이지를 로드하거나 브라우저에서 다른 요청을 채우려는 동안 한 서버가 액세스하는 다른 서버로부터 응답을 받지 못했을음 의미한다. 서버간의 네트워크 오류이거나 실제 서버의 문제이므로 장치나 인터넷 연결의 문제는 아니다.

참고 : HTTP | MDN ; status code

3. Software Architecture and Design

Clean Architecture (클린 아키텍처)

*쓰니가 이해하기에는 다소 어려운 개념이었습니다. 따라서 본 포스팅에는 쓰니가 이해한 의미만 담는것으로 하고, 다른 포스팅에 좀 더 자세한 설명을 써보겠습니다.

• 개념 : Robert C. Martin (Uncle Bob)의 블로그에 따르면, 소프트웨어를 계층적으로 분리하고, 시스템에 제약된 제약조건에 의해 좌우 되지 않는 독립적인 아키텍처로 시스템을 생성하는 것.
  http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Clean Coder Blog

SOLID Obejct Oriented Designing

객체지향 설계의 목표는 설계한 소프트웨어의 유지보수가 용이하도록 구현하고, 기능적 측면에서도 원하는 기능이 완벽하게 구현되도록 프로그래밍하는 것입니다. 

• S:SRP ; 단일 책임 원칙 (Single responsibility principle)
  한 클래스는 하나의 책임만 가져야 한다.
• O:OCP ; 개방-폐쇄 원칙 (Open/closed principle)
  “소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.”
• L:LSP ; 리스코프 치환 원칙 (Liskov substitution principle)
  “프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.” 계약에 의한 설계를 참고하라.
• I:ISP ; 인터페이스 분리 원칙 (Interface segregation principle)
  “특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
• D:DIP ; 의존관계 역전 원칙 (Dependency inversion principle)
  프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.”의존성 주입은 이 원칙을 따르는 방법 중 하나다.

참고 : SOLID 나무위키