6. 프로그래밍 공통

RestFul API

• HTTP 통신을 Rest 설계 규칙을 잘 지켜 개발한 API
• RestFul하게 만든 API는 요청을 보내는 주소 그 모습 자체만으로 어떤 것을 요청하는지 파악 가능
• REST 설계 규칙: URI는 정보의 자원만을 표현하고 자원의 상태와 행위는 HTTP METHOD에 명시하는 것을 말한다.
• 자원: 소프트웨어가 관리하는 모든 것(문서, 그림, 데이터, 해당 소프트웨어 자체)
• 상태: 데이터 요청 시점에 자원의 상태 전달(JSON, XML을 이용한 데이터 전달)
• 표현: 그 자원을 표현하기 위한 이름
• REST: 어떤 자원에 대해 CRUD 연산을 수행하기 위해 URI로 GET, POST 방식을 사용하여 요청을 보내며 요청을 위한 자원은 특정한 형태로 표현된다.
  • 구성요소: URI, METHOD, Representation of Resource
  • 특징: Server-Client 구조, Statelss, Cacheable, Layered System, Uniform Interface, Self-Descriptiveness
  • 설계 규칙: 1) URI는 명사를 사용 2) /로 계층 관계를 표현 3) URI 마지막 문자로 /를 포함하지 않음 4) _을 사용하지 않고 -을 사용 5) URI는 소문자로만 구성 6) HTTP 응답 상태 코드를 사용

HTTP 상태 코드

• 1xx: 정보 응답
• 2xx: 성공 응답
  • 200 OK: 요청 정상 처리
  • 201 Created: 생성에 대한 요청을 받았으며 그 결과로 서버가 새 리소스 작성 (POST, PUT)
• 3xx: 리다이렉트: 클라이언트의 요청에 대해 적절한 위치를 제공하거나 대안의 응답을 제공
  • 301 Moved Permanently: 요청한 리소스의 URI가 변경되었음을 의미한다.
  • 304 Not Modified: 이전의 요청과 비교해 달라진 것이 없음
• 4xx: 클라이언트 요청 오류
  • 401 Unauthorized: 클라이언트가 인증되지 않았거나 유효한 인증 정보가 부족하여 요청 거부
  • 404 Not Found: 클라이언트가 요청한 URI를 찾을 수 없음
• 5xx: 서버 오류: 클라이언트의 정상적인 요청에도 불구하고 서버 문제로 응답할 수 없음
  • 503 Service Unavailable: 현재 서버는 일시적으로 사용이 불가

URI와 URL의 차이점

• URL은 Uniform Resource Locator의 약자로 인터넷 상의 자원의 위치를 말하고 URI는 Uniform Resource Identifier의 약자로 인터넷 상의 자원을 식별하기 위한 문자열의 구성으로 URI가 URL보다 포괄적인 범위라고 할 수 있다.

프레임워크와 라이브러리의 차이점

• 제어 흐름에 대한 주도권이 어디에 있는가에 있다. 프로그램의 전체적인 제어 흐름은 프레임워크에게 있고 개발자는 그 안에서 라이브러리에 대한 흐름을 갖는다. 여기서 개발자의 제어권을 프레임워크에게 넘김으로 신경써야 할 것을 줄일 수 있는데 이를 제어의 역전(Inversion Of Control)이라고 한다.

Call By Value와 Call By Reference

• 값에 의한 호출: 인자로 받은 값을 복사하여 처리하는 방식
  • 값을 복사하여 처리하기 때문에 원래의 값이 보존되지만 복사하므로 메모리 사용량 증가
• 참조에 의한 호출: 인자로 받은 값의 주소를 참조하여 직접 저장해 값에 영향을 주는 방식
  • 값을 복사하지 않고 직접 참조하기 때문에 빠르고 원래의 값은 영향을 받는다.

절차지향 프로그래밍과 객체지향 프로그래밍

• 절차지향: 순차적인 처리를 중요시하는 프로그래밍 기법으로 컴퓨터 처리구조와 유사해 실행속도가 빠르다.
• 객체지향: 실제 세계 사물들을 객체로 모델링하여 개발을 진행하는 프로그래밍 기법으로 상대적으로 실행속도가 느리다.

OAuth 2.0 흐름

• 사용자가 클라이언트에게 사용 요청을 보냄 => 클라이언트는 권한 서버에 권한 부여 승인 코드 요청을 보냄 => 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 띄워 사용자에게 보여줌 => 사용자가 로그인 하면 권한 서버는 권한 부여 승인 코드 요청에 전달받은 redirect url로 Authorization code를 전달 => Authorization code는 권한 서버에서 제공하는 API를 통해 Acess Token으로 교환된다.

대칭키와 비대칭키

• 대칭키: 암호화와 복호화에 같은 암호 키를 쓰는 알고리즘
• 비대칭키: 암호화와 복호화를 할 때 서로 다른 키를 쓰는 알고리즘

TDD(Test-Driven-Development)

• 작은 단위의 테스트 케이스를 작성하고 그에 맞는 코드를 작성하여 테스트를 통과한 후에 상황에 맞게 리팩토링하는 테스트 주도 개발 방식
  • 기능의 추가, 변경, 삭제로 인한 영향도를 쉽게 파악 가능
  • 예상하지 못한 오류에 대한 피드백을 할 수 있음
  • 좋은 설계로 작성되게끔 코드를 유도할 수 있음
  • 기능 정의의 문서 역할
  • 실수를 줄여줌

MSA(MicroService Architecture)

• 1개의 시스템을 독립적으로 배포 가능한 각각의 서비스로 분할
• 각각의 서비스는 API 를 통해 데이터를 주고 받으며 1개의 큰 서비스를 구성
• 모든 시스템의 구성요소가 한 프로젝트에 통합되어 있는 한계점을 극복하고자 등장
• 장점: 일부 서비스에 장애가 발생하더라도 전체 서비스에 영향이 없다. 각각의 서비스들은 서로 다른 언어와 프레임워크로 구성될 수 있다. 서비스의 확장이 용이하다.
• 단점: 서비스가 분리되어 있어 테스트나 트랜잭션 처리가 어렵다. 서비스 간에 API로 통신하므로 그에 대한 비용이 발생한다. 서비스 간 호출이 연속적이기 때문에 디버깅 및 에러 트레이싱이 어렵다.