객체 지향 프로그래밍
객체 지향 프로그래밍의 장점
- 이미 작성한 코드에 대한 재사용성이 높다.
- 객체 단위로 코드가 나눠져 작성되기 때문에 디버깅이 쉽고 유지보수에 용이하다.
- 데이터 모델링을 할 때 객체와 매필하는 것이 수월하기 때문에 요구사항을 보다 명확하게 파악하여 프로그래밍 할 수 있다.
객체 지향적 설계 원칙
- SRP(Single Resposibility Principle) : 단일 책임 원칙
- 클래스는 단 하나의 책임을 가져야 하며 클래스를 변경하는 이유는 단 하나의 이유여야 한다.
- OCP(Open-Closed Principle) : 개방-폐쇄 원칙
확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다. - LSP(Liskov Substitution Principle) : 리스코프 치환 원칙
상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다. - ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다. - DIP(Dependency Inversion Principle) : 의존 역전 원칙
고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.
Restful API
Restful API란?
REST란 , REpresentational State Transfer 의 약자이다.
REST에서 "Representational State"는 자원의 상태를 표현하는 것을 의미한다. 시스템의 리소스를 표현하는데 사용되는 표현은 클라이언트와 서버 간에 주고받는 데이터 형식이다. 주로 JSON 혹은 XML 형태의 데이터를 사용한다.
"Transfer"는 클라이언트와 서버 간의 데이터 전송을 의미한다. REST는 HTTP 프로토콜을 기반으로 하며, 클라이언트는 HTTP 메소드(GET, POST, PUT, DELETE 등)를 사용하여 서버의 리소스를 조작하고 요청한다.
따라서, REST는 웹 시스템에서 클라이언트와 서버 간의 상호작용을 위한 아키텍처 스타일로서, 자원의 표현과 상태 전송을 중심으로 하는 웹 API 디자인을 의미한다.
REST 6가지 원칙
Uniform Interface (일관된 인터페이스)
- 클라이언트와 서버 간의 통신을 위한 인터페이스가 일관성 있게 설계되어야 한다.
- 리소스 식별, 리소스 조작을 위한 통일된 방식을 사용하고, 메시지 형식 및 프로토콜도 통일된 규칙을 따라야 함
Stateless
- 클라이언트와 서버 간의 세션 상태를 서버에 저장하지 않고, 각 요청이 독립적으로 처리되도록 설계되어야 한다. 클라이언트는 필요한 모든 정보를 요청에 포함시켜야 하며, 서버는 각 요청을 별개의 요청으로 이해하고 처리한다. -> 서버의 확장성과 재사용성이 향상됨.
Caching
- 서버 응답을 클라이언트나 중간 서버에서 캐시로 저장하여, 동일한 요청이 반복될 때 캐시된 응답을 사용함으로써 네트워크 대역폭을 절약하고 응답 시간을 단축시킨다.
Client-Server
- RESTful API는 클라이언트와 서버 간의 엄격한 역할 분리를 한다. 서로의 역할을 엄격히 분리하여 서버와 클라이언트 간의 상호작용이 단순하도록 한다.
Hierarchical System
- 계층 구조를 가진다. 클라이언트는 리소스에 대한 직접적인 접근만 가능하며, 중간 서버는 인증, 보안, 로드 밸런싱 등의 기능을 담당한다. -> 시스템의 확장성과 유연성을 높인다.
Code on demand
- 필요에 따라 서버로부터 실행 가능한 코드를 클라이언트에게 전달할 수 있는 옵션을 제공 -> 웹 브라우저에서 JavaScript 코드를 다운로드하고 실행하는 방식
REST API 장점
- Open API 를 제공하기 쉽다
- 멀티플랫폼 지원 및 연동이 용이하다.
- 원하는 타입으로 데이터를 주고 받을 수 있다.
- 기존 웹 인프라(HTTP)를 그대로 사용할 수 있다.
REST API 단점
- 사용할 수 있는 메소드가 한정적이다.
- 분산환경에는 부적합하다.
- HTTP 통신 모델에 대해서만 지원한다.
어제보단 오늘이 더 강한 웹/앱 개발자입니다