mato-up

https://aws.amazon.com/ko/what-is/restful-api/

해당 글을 참고하여 작성하였습니다. 

RESTful API란?

• 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스. 
• 대부분의 비즈니스 애플리케이션은 다른 내부 애플리케이션 및 서드 파티 애플리케이션과 통신함.

API(Application Programming Interface)란? 

• 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의. 
• 개발자는 다른 애플리케이션이 프로그래밍 방식으로 애플리케이션과 통신할 수 있도록 API를 표시하거나 생성한다. 
• 예시
  • 근무 시간 기록 애플리케이션은 직원의 전체 이름과 날짜 범위를 요청하는 API를 표시한다. 
  • 이 정보가 수신되면 내부적으로 직원의 근무 시간 기록을 처리하고, 해당 날짜 범위에서 근무한 시간을 반환한다. 
  • 웹 API는 클라이언트와 웹 리소스사이의 게이트웨이. 
    • 클라이언트: 웹에서 정보에 액세스 하려는 사용자이다. 클라이언트는 API를 사용하는 사람이거나 소프트웨어시스템일 수 있다. 예를 들어 개발자는 날짜 시스템에서 날씨 데이터에 액세스하는 프로그램을 작성할 수 있다.(소프트웨어시스템인 경우) 또는 사용자가 날씨 웹 사이트를 직접 방문할 때 브라우저에서 동일한 데이터에 액세스할 수 있다.( 사람인 경우)
    • 리소스: 다양한 애플리케이션이 클라이언트에게 제공하는 정보. 리소스는 이미지, 동영상, 텍스트, 숫자 또는 모든 유형의 데이터일 수 있다. 클라이언트에 리소스를 제공하는 시스템을 서버라고도 한다. 조직은 API를 사용하여 리소스를 공유하고 보안, 제어 및 인증을 유지하면서 웹 서비스를 제공한다. 또한 API는 특정 내부 리소스에 액세스할 수 있는 클라이언트를 결정하는 데 도움이 된다. 

REST(Representational State Transfer)란?

• API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처. 
• REST는 처음에 인터넷과 같은 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어졌다. 
• REST 기반 아키텍처를 사용하여 대규모의 고성능 통신을 안정적으로 지원할 수 있다. 
• 쉽게 구현할 수 있고, 수정할 수 있기 때문에 여러 플랫폼에서 사용할 수 있다. 
• API개발자는 여러 아키텍처를 사용하여 API를 설계할 수 있다.
• REST API: REST 아키텍처 스타일을 따르는 API
• RESTful 웹 서비스: REST 아키텍처를 구현하는 웹 서비스.

REST 아키텍처 스타일의 원칙

• 균일한 인터페이스
  
  • 모든 RESTful 웹 서비스 디자인의 기본이며 서버가 표준 형식으로 정보를 전송함을 나타낸다. 형식이 지정된 리소스를 REST에서는 표현이라고 부른다. 이 형식은 서버 애플리케이션에 있는 리소스의 내부 표현과 다를 수 있다. 
  • 예를들어, 서버는 데이터를 텍스트로 저장하되, HTML 표현 형식으로 전송할 수 있다. 
  • 균일한 인터페이스의 4가지 아키텍처 제약 조건
    1. 요청은 리소스를 식별해야 한다. 이를 위해 균일한 리소스 식별자를 사용한다. 
    2. 클라이언트는 원하는 경우 리소스를 수정하거나 삭제하기 충분한 정보를 리소스 표현에서 가지고 있다. 서버는 리소스를 자세히 설명하는 메타데이터를 전송하여 이 조건을 충족한다. 
    3. 클라이언트는 표현을 추가로 처리하는 방법에 대한 정보를 수신한다. 이를 위해 서버는 클라이언트가 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터가 포함된 명확한 메시지를 전송한다. 
    4. 클라이언트는 작업을 완료하는 데 필요한 다른 모든 관련 리소스에 대한 정보를 수신한다. 이를 위해 서버는 클라이언트가 더 많은 리소스를 동적으로 검색할 수 있도록 표현에 하이퍼링크를 넣어 전송한다. 
• 무상태
  • REST 아키텍처에서 무상태는 서버가 이전의 모든 요청과 독립적으로 모든 클라이언트 요청을 완료하는 통신 방법을 나타낸다. 
  • 클라이언트는 임의의 순서로 리소르를 요청할 수 있으며 모든 요청은 무상태이거나 다른 요청과 분리된다. 
  • 서버가 매번 요청을 완전히 이해해서 이행할 수 있음을 의미한다. 
• 계층화 시스템
  
  • 계층화된 시스템 아키텍처에서 클라이언트는
    • 클라이언트와 서버 사이의 다른 승인된 중개자에게 연결할 수 있으며
    • 여전히 서버로부터도 응답을 받는다. 
  • 서버는 요청을 다른 서버로 전달할 수도 있다. 
  • 클라이언트 요청을 이행하기 위해 함께 작동하는 보안, 애플리케이션 및 비즈니스 로직과 같은 여러 계층으로 여러 서버에서 실행되도록 RESTful 웹 서비스를 설계할 수 있다. 
  • 이러한 계층은 클라이언트에 보이지 않는 상태로 유지된다. 
• 캐시 가능성
  • RESTful 웹 서비스는 서버 응답 시간을 개선하기 위해 클라이언트 또는 중개장에 일부 응답을 저장하는 프로세스인 캐싱을 지원한다. 
  • 예시
    • 모든 페이지에 공통 머리글 및 바닥글 이미지가 있는 웹 사이트를 방문할 시, 새로운 웹 사이트 페이지를 방문할 때마다 서버는 동일한 이미지를 다시 전송해야 한다. 
    • 이를 피하기 위해 클라이언트는 첫 번째 응답 후에 해당 이미지를 캐싱하거나 저장한 다음 캐시에서 직접 이미지를 사용한다. 
    • RESTful 웹 서비스는 캐시 가능 또는 캐시 불가능으로 정의되는 API응답을 사용하여 캐싱을 제어합니다. 
• 온디맨드(On-Demand) 코드
  • REST 아키텍처 스타일에서 서버는 소프트웨어 프로그래밍 코드를 클라이언트에 전송하여 클라이언트 기능을 일시적으로 확장하거나 사용자 지정할 수 있다. 
    • 예시
      • 웹 사이트에서 등록 양식을 작성하면 브라우저는 잘못된 전화번호와 같은 실수를 즉시 강조 표시한다. 
      • 서버에서 전송한 코드로 인해 이 작업을 수행할 수 있다. 
    • 주문형 코드라고 이해. 

RESTful API를 사용했을 때의 이점.

• 확장성
  
  • REST API를 구현하는 시스템은 REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적인 크기 조정이 가능하다. 
  • 무상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버 로드(서버 부하..?)를 제거한다. 
  • 잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로 또는 완전히 제거한다. 
  • 이러한 모든 기능은 성능을 저하시키는 통신 병목 현상을 일으키지 않으면서 확장성을 지원한다. 
• 유연성
  • RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원한다. 
  • 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리한다. 
  • 서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않는다. 
  • 애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상시킨다. 
  • 예를 들어, 개발자는 애플리케이션 로직을 다시 작성하지 않고도 데이터베이스 게층을 변경할 수 있다. 
• 독립성
  • REST API는 사용되는 기술과 독립적이다. 
  • API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있다. 
  • 또한 통신에 영향을 주지 않고 양쪽(클라이언트-서버)의 기본 기술을 변경할 수 있다.

RESTful API의 작동 방법

• RESTful API의 기본 기능은 인터넷 브라우징과 동일하다. 
• 클라이언트는 리소스가 필요할 때 API를 사용하여 서버에 접속한다. 
• API 개발자는 서버 애플리케이션 API 문서에서 클라이언트가 REST API를 어떻게 사용해야 하는지 설명한다. 
• 모든 REST API 호출에 대한 일반 단계
  1. 클라이언트가 서버에 요청을 전송한다. 클라이언트가 API 문서에 따라 서버가 이해하는 방식으로 요청 형식을 지정한다. 
  2. 서버가 클라이언트를 인증하고 해당 요청을 수행할 수 있는 권한이 클라이언트에 있는지 확인한다. 
  3. 서버가 요청을 수신하고 내부적으로 처리한다. 
  4. 서버가 클라이언트에 응답을 반환한다. 응답에는 요청이 성공했는지 여부를 클라이언트에 알려주는 정보가 포함된다. 응답에는 클라이언트가 요청한 모든 정보도 포함된다. 

RESTful API 클라이언트 요청의 구성요소.

RESTful API에는 다음과 같은 주요 구성 요소를 포함하는 요청이 필요하다. 

• 고유 리소스 식별자
  • 서버는 고유한 리소스 식별자로 각 리소스를 식별한다.
  • REST 서비스의 경우 서버는 일반적으로 URL(Uniform Resource Locator)사용하여 리소스 식별을 수행한다. 
    • URL은 리소스에 대한 경로를 지정한다. 
    • URL은 웹페이지를 방문하기 위해 브라우저에 입력하는 웹 사이트 주소와 유사한다.
    • 요청 엔드포인트라고도 하며, 클라이언트가 요구하는 사항을 서버에 명확하게 지정한다. 
• 메서드
  
  • 개발자는 종종 Hypertext Transfer Protocol(HTTP)을 사용하여 RESTful API를 구현한다. 
  • HTTP메서드는 리소스에 수행해야 하는 작업을 서버에 알려준다. 
  • 일반적인 HTTP메서드
    1. GET
       
       • 클라이언트는 GET을 사용하여 서버의 지정된 URL에 있는 리소스에 액세스한다.
       • GET 요청을 캐싱하고 RESTful API 요청에 파라미터를 넣어 전송하면 전송 전에 데이터를 필터링하도록 서버에 지시할 수 있다.
    2. POST
       
       • 클라이언트는 POST를 사용하여 서버에 데이터를 전송한다. 
       • 여기에는 요청과 함께 데이터 표현이 포함된다.
       • 동일한 POST요청을 여러 번 전송하면 동일한 리소스를 여러 번 생성하는 부작용이 있다.
       • CRUD에서 Create라고 생각.
    3. PUT
       • 클라이언트는 PUT을 사용하여 서버의 기존 리소스를 업데이트 한다.
       • POST와 달리 RESTful 웹 서비스에서 동일한 요청을 여러 번 전송해도 결과는 동일한다.
       • CRUD에서 Update로 생각.
    4. DELETE
       
       • 클라이언트는 DELETE요청을 사용하여 리소스를 제거한다.
       • DELETE요청은 서버 상태를 변경할 수 있다. 
       • 그러나 사용자에게 적절한 인증이 없으면 요청은 실패한다.
• HTTP 헤더
  1. 데이터
  2. 파라미터
     • URL 세부정보를 지정하는 경로 파라미터
     • 리소스에 대한 추가 정보를 요청하는 쿼리 파라미터.
     • 클라이언트를 빠르게 인증하는 쿠키 파라미터.

RESTful API 인증 방법

• HTTP 인증 
  • 기본인증 : 요청 헤더에 사용자 이름과 암호를 넣어 전송하며 이 페어를 base64로 인코딩한다. 
  • 전달자 인증 : 전달자토큰이란 서버가 로그인 요청에 대한 응답으로 생성하는 암호화된 문자열이며, 클라이언트는 리소스에 액세스하기 위해 요청 헤더에 토큰을 넣어 전송한다. 
• API 키  : 서버는 고유하게 생성된 값을 최초 클라이언트에 할당하며, 클라이언트는 리소스에 액세스하려고 할 때마다 고유한 API 키를 사용하여 본인을 검증한다. 이 경우 클라이언트가 이 키를 전송해야 해서 네트워크 도난에 취약하다.
• OAuth : 모든 시스템에 대해 매우 안전한 로그인 액세스를 보장하기 위해 암호와 토큰을 결합한다. 먼저 암호를 요청하고 추가 토큰을 요청한다. 특정 범위와 수명으로 언제든지 토큰 확인이 가능하다. 

RESTful API 서버 응답에 포함된 내용.

• 상태 표시줄 : 상태 표시줄에는3자리 상태 코드가 있다. (2XX : 성공, 3XX: URL 리디렉션 등)
• 메시지 본문 : 리소스 표현이 포함된다. 서버는 요청 헤더에 포함된 내용을 기반으로 적절한 표현 형식을 선택한다. (JSON->JSON)
• 헤더 :  응답에 대한 추가 컨텍스트를 제공하고 서버, 인코딩, 날짜 및 콘텐츠 유형과 같은 정보를 포함한다.

https://blog.wishket.com/%ED%8C%8C%EC%9D%B4%EC%96%B4%EB%B2%A0%EC%9D%B4%EC%8A%A4firebase%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-%ED%8C%8C%EC%9D%B4%EC%96%B4%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%8B%AC%EC%B8%B5-%ED%83%90/

https://blog.wishket.com/%ED%8C%8C%EC%9D%B4%EC%96%B4%EB%B2%A0%EC%9D%B4%EC%8A%A4firebase%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-%ED%8C%8C%EC%9D%B4%EC%96%B4%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%8B%AC%EC%B8%B5-%ED%83%90-2/

https://blog.wishket.com/%ED%8C%8C%EC%9D%B4%EC%96%B4%EB%B2%A0%EC%9D%B4%EC%8A%A4firebase%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-%ED%8C%8C%EC%9D%B4%EC%96%B4%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%8B%AC%EC%B8%B5-%ED%83%90-3/

https://aws.amazon.com/ko/what-is/xml

윗 글을 참고하여 작성하였습니다. 

XML이란?

• 데이터를 정의하는 규칙을 제공하는 마크업 언어이며 다른 프로그래밍 언어와 달리 자체적으로 컴퓨팅 작업을 수행할 수 없다. 
• 마크업 기호를 이용하여 데이터에 대한 추가 정보를 제공함으로써 브라우저와 데이터 처리 애플리케이션 등의 다른 소프트웨어는 이 정보를 사용하여 정형 데이터를 효율적으로 처리한다. 

XML 태그

• xml에서 태그라고 하는 마크업 기호를 사용하여 데이터를 정의한다. 
• <book>, <title>, <author>등과 같은 태그를 만드는 것이 그 예이다. 

XML 사용의 이점

• 비지니스 간 트랜잭션 지원
• 데이터 무결성 유지
• 검색 효율성 향상
• 유연한 애플리케이션 설계

XML의 용도

• 데이터 전송
  • ex) 웹 사이트에서의 날짜 표시형식: MM/DD/YYYY, 회계 시스템에서의 날짜 표시형식: DD/MM/YYYY
• 웹 애플리케이션
• 설명서
• 데이터 유형

XML 파일의 구성 요소

• XML문서: <xml></xml> 태그 내의 콘텐츠
• XML선언
• XML요소: 문서 내에서 만드는 다른 모든 태그

XML과 HTML의 차이점

출처

https://devcompass.co.kr/%EC%95%B1-%EC%A0%9C%EC%9E%91/

곧 있을 면담에서 순서 및 방향을 잡아주실 것 같지만 감이 오지 않아서 앱이 개발되는 과정을 찾아보았다. 

잘 정리되어있는 문서를 발견하였고, 내 수준에서 필요한 부분만 정리해보았다. 자세하고 전문적인 정보는 해당 링크에서 보길 바란다.

서비스 구상 및 프로젝트 구성 -> 앱 기획 -> 기술 검토 및 견적 -> 앱 디자인 -> 서버 개발 -> 앱 개발 -> 앱 테스트 -> 앱 배포

1. 서비스 구상 및 프로젝트 구성

2. 앱 기획

1) 플로우 차트 작성

2) 와이어 프레임 작성 (카카오 OVEN 추천:https://ovenapp.io/)

3) 상세기능리스트 작성

3. 기술 검토 및 견적 

1) 서버 사용 여부 결정

- 개인정보 및 비번은 보안이 철저해야한다. 

- 삭제 되어도 상관 없는 정보나 캐시는 사용자 스마트콘 로컬 DB에 저장 가능하지만 중요한 정보는 서버에서 따로 관리하여야 한다. 따라서 대부분 서버를 두어 데이터의 저장과 처리를 담당한다. 

2) 서버 아키텍처 설계

-개발 언어, 프레임 워크 결정 

-서버 사양, 네트워크, DB사양 결정

-프로젝트가 큰 경우 소스 형상 관리, 이슈 트래킹, 빌드 및 배포 시스템 구성

3) 앱 아키텍처 설계

- 서비스하고자 하는 기능과 앱 배포 방법, 개발인력 등을 고려하여 결정해야 한다. 

4) 지원 플랫폼 결정 (안드로이드, iOS)

5) 지원 API 버전 결정

• 안드로이드 버전 정보 – wikipeida
• iOS 버전 정보 – wikipedia

6) 지원 디바이스 결정(파편화 문제)

7) 프로젝트 기간 및 견적 도출 (앱 출시 후 운영 계획 및 비용까지 고려)

-서버 아키텍처와 앱 아키텍처 설계, 지원 플랫폼, 지원 API 버전, 지원 디바이스 목록을 모두 문서화하여 정리한다. 

2. 앱 디자인

1) 디자인 가이드 검토

안드로이드 디자인 가이드

iOS 디자인 가이드

2) 유사 어플리케이션의 UX/UI 사례 검토

-핀터레스트 등

3) 테마 선택 

- 안드로이드와 iOS에서 제공하는 스타일과 테마 존재. 

- 앱의 주 색상과 보조 색상 선택

4) 테마 커스텀 작업

3. API 서버 개발

1) 인터페이스 설계

- 서버와 앱이 주고 받을 데이터와 인터페이스 설계해야 함

- 앱 개발= 클라이언트 개발=프론트엔드 개발

-서버 개발=백엔드 개발

-API = Application Programming Interface , API방식에는 SOAP, /RESTful이 있다.  요즘은 RESTful 사용

-데이터 포맷은 JSON이나 XML사용

2) DB 설계

-DB에는 RDB와 noSQL로 나뉨. 

3) 개발 환경 세팅 및 개발 진행

4  앱 개발

5. 앱 테스트

1. 프로젝트 설계란?

프로젝트 설계는 대표적으로 '프로세스 설계', '인터페이스 설계', '데이터 설계'로 나눌 수 있다. 

CRUD매트릭스란, 프로세스와 데이터의 사용 관계를 표 관계로 나타낸 산출물이다. 

2. 프로세스 설계

프로세스 설계 도구에는 프로세스 맵과 DFD가 있다. 

3.인터페이스 설계

4.데이터 설계

데이터 설계는 ERD툴을 이용하여 한다. 

1) 요구사항 분석 : 요구사항 명세서, 프로세스 설계서, 인터페이스 설계서 참고

2) 개념 데이터 설계 : 관리하고자 하는 정보와 그 관계를 설계

3) 논리 데이터 설계 : 개념 단계에서 도출한 정보의 속성 정의, 식별자 확정, 정규화 수행

4) 물리 데이터 설계 : 물리적 데이터베이스에서 이식 가능하도록 속성을 타입과 크기 정의, 제약 조건과 인덱스 정의, 비정규화 수행

5)  테이블 정의서 작성 : 테이블, 컬럼에 주석을 추가해서 최종 개발에 활용할 테이블 정의서 작성