[풀스택] JSON / RESTful API / CRUD

 

 

 

 

https://sohyeonkim-dev.tistory.com/171

[풀스택] HTTP's streaming / Curl / SOA / Microservice

* 앞서 살펴본 내용 - 20년의 시간 압축한 것 
SOA -> SOAP -> HTTP + XML ->  
microservice -> Cloud computing -> Docker + 쿠버네틱스
걔네가 뭘 하냐? HTTP 기반의 JSON을 주고 받는다 
-> JSON -> REST, RESTful / CRUD

 

 

 

 

JSON Data Format

JavaScript Object Notation

• JS 언어의 데이터 표현 방식으로 다른 언어들로 확산된 것
• 웹 브라우저는 JS 번역기를 내장하기에 웹 서비스에 유리함
• 문자열로 이루어져 있으며, JSON 객체로 변환이 가능함
• 확장자 .json과 타입 application/json 사용이 활용됨
• 무상태, 실시간 서버 대 브라우저 통신 프로토콜로 많이 활용됨
  • 서버와 서버 ,앱과 서버가 JSON data를 주고 받음
• 기본적인 프로그래밍 언어의 데이터 형태를 지원
  • 정수, 실수 (고정/부동 소수점), 문자열
  • 배열 : [ a, b, c ]
  • 객체 : { “member1” : “value1”, “member2” : “value2” }
    -> dict 형태로 제공
• 순수한 ‘데이터 포맷’임 (메서드 표현 불가)
• 문자열과 프로퍼티의 이름 작성시 큰 따옴표만 사용해야 함
• 파이썬 딕셔너리의 key - value 값으로 저장된 것  
• 리스트(members)형태로 여러 개 아이템이 있다 (아래 예시의 entries)

 

 

  

https://emcien.com/json-format/

 

 

 

JSON Standard Library in Python

• python 표준 라이브러리
• import json
• python이 알아서 JSON 객체 <-> python 객체 변환
• JSON과 python 데이터 형식 변환 1:1로 매칭 가능

 

• 대표 함수
  •  json.dump() : dict 데이터를 json 포맷 파일로 저장
  • json.load() : json 파일을 읽어서 dict 데이터로 변환
  • json.dumps() : dict 데이터를 json 포맷 문자열로 변환
  • json.loads() : json 포맷 문자열을 dict 데이터로 변환
• 파이썬 입장에서 JSON으로 밀어넣는 것 -> dump
• JSON 객체를 파이썬으로 가져오는 것 -> load
• JSON 파일 -> JSON 문자열 : s를 붙인다 
• python 가져오는 형식은 모두 python dict data

 

• 프로그래밍 언어가 달라도 상관 X
• 정보를 주고 받는 언어가 될 수 있다
• 정보의 형태는 JSON
• 정보를 실어 나르면서, 추가적인 작업을 하는 것 -> REST

 

 

 

REST & RESTful

• HTTP 구조에 기반한, 프로그램의 설계 구조
• 일종의 철학, 개념, 소프트웨어 구현의 가이드라인
• 그 철학을 기반으로, 구체적인 형태 -> Restful한 API라고 함 

 

•  REST
  • Software architectural style 
    that was created to guide the design and development of the architecture for the WWW
• RESTful
  • Any web service that obeys the REST constraints is informally described as RESTful
  • Such a web service must provide its Web resources in a textual representation
    and allow them to be read and modified with 
    a stateless protocol and a predefined set of operations
  • 상태가 없다 == 앞선 처리에 대한 기억이 없다
  • memeryless -> 현 상태에 받은 http에 충실함

 

 

 

 

REST 구조에 대한 조건

• 인터페이스 일관성
  • 일관적인 인터페이스로 분리되어야 함
  • 함수를 호출할 때의 형태, 응답할 때의 형태 등
    명확하게 정의되어야 함 
• 무상태(Stateless)
  • 각 요청 간 클라이언트의 콘텍스트는 서버에 저장 X
  • 이전 상황에 대한 것은 없다. 
  • 지금 들어온 요청에 대해, A API서버가 받고, 
    이후 다음 요청을 B서버가 받아도 상관없다
  • 독립적으로 동작한다
• 캐시 처리 가능(Cacheable)
  • 클라이언트는 응답을 캐싱할 수 있어야 함
  • 네트워크, 서버, 클라이언트의 성능을 올리기 위해 사용
  • 한번 받아두고, 쓸 수 있으면 계속 사용한다 -> Cache 캐시!
• 계층화(Layered System)
  • 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는 지를 알 수 없음. 
  • 중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 규모 확장성을 향상시키는 데 유용함
  • 프록시 서버 말하는 것?
  • 최적화, 성능 올리는 작업을 할 수 있다
• Code on demand (optional) - 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장 시킬 수 있음
  
  
• 클라이언트/서버 구조 
  • 아키텍처를 단순화시키고 작은 단위로 분리 (decouple)
  • 클라이언트 - 서버의 각 파트가 독립적으로 개선될 수 있도록 함

 

 

• 사실은 HTTP 설명을 한 것 
• HTTP 기반으로 동작하는 클라이언트, 서버 구조
• 웹 브라우저 화면을 채우기 위한 컨텐츠 실어나르는 것 X
  A 컴퓨터와 B 컴퓨터 사이의 함수 호출 
  기능 요청과 전송을 다루는 것 (request & response)
  컨텐츠를 주고 받는 목적이 아님!
• GET -> 파일 요청 X 
  -> 숫자 두 개 주고 계산하는 것
• URL -> 원래는 파일 디렉토리(위치)를 나타내는 것
• BUT HTTP에 기반하여, 
  REST 철학을 따르는 기능을 요청하고, 그에 따른 응답을 받는 것

 

 

 

•  HTTP Req/Res 메시지를 통한 Client & Server 간 정보 송수신
• 함수/메소드 호출과 유사한 형태를 인터넷을 통해서 수행하는 것
• 예를 들어
  http://localhost/ 서버를 다음처럼 개발할 수 있다
  • http://localhost/my_api/로 해서, 서버가 “my_api”에 대응해서 제공하는 기능을 호출
  • 더 이상 “my_api”는 원래 의미의 directory 개념이 아님
  • http://localhost/my_api/{문자열} 처럼 HTTP Req를 Server에 보내면,
    서버는 {문자열}과 HTTP Req의 Body로 전달한 값을 입력 파라메타로 하여,
    GET/POST/PUT/DELETE에 상응하는 기능을 수행하고, 
    결과를 Client에 리턴 하도록 할 수 있음
  • GET을 Read로 간주하여, 
    {문자열}을 Key 값으로 하여,
    서버의 record들을 찾아 대응하는 Value를 리턴
  • POST을 Create로 간주하여, 
    {문자열}을 Key 값으로 하고,
    HTTP Req의 Body에 해당하는 값을 Value로 하는 record를 생성

 

 

 

Simple Guideline for REST API Design

• 수학 공식처럼 명확한 규칙은 없음
• JSON 포맷으로 정보를 송수신 함
• 통상 CRUD(Create, Read, Update, and Delete)를 따름
• 가장 많이 사용되는 RESTful 구현 방식

 

• 서버에 있는 정보를 다른 곳에서 접근할 때
• DB에 정보를 넣을 때 -> 일단 record를 create 
• 필요한 경우, record를 read, update, delete

 

• POST 
• create new, unique thing
• request & 보내고 싶은게 있으면 URL or JSON 에 넣어서 전달
• 파일을 전달하는게 아니다!

 

• 항상 저런 식으로 매핑?
• 꼭 그런건 아니지만, 상식적으로 
• GET 이 read -> PUT 을 update 로 둔다.
• 회사마다 구체적인 구현은 자체적으로 정의함

 

 

 

https://dev.to/ijsathi/basic-crud-operations-hg0

 

 

 

REST API 설계를 위한 도구들

•  Flask-RESTX
  •  Flask에서 REST API 개발이 용이하도록 하는 확장 기능
  • 1) Flask 구현 
    • flask 오브젝트 만들고,
      루트 디렉토리로 오는 함수가 있다면, 
      hello() <- 수행해야 할 동작을 써둔 것 
      파일을 찾아가는 것이 아니라, 그에 따른 기능을 한다! 
  • 2) Flask-RESTX
    • 아까는 app으로 프로그램을 구동
      이번에는 api로 프로그램을 만드는 것이 차이점
    • 내가 받았을 때, 처리하고 싶은 메소드 -> class 형태
      hello url로 오는 get request가 오면 얘를 실행 
      post, put, delete 뒤에 따를 동작을 개발자가 작성
      RESTul api의 CRUD 철학을 따르는 것 
      
      
• Swagger
  • 초기 HTTP의 의도는, 디렉토리의 파일 전송
    하지만 CRUD 기능을 수행
    요청 - 결과를 받는 형식으로 진화한 것
  • fulsk-restX -> 스웨거를 이미 갖고 있음 
  • 웹사이트에서 직접 서버에 test 해볼 수 있다!

 

 

 

 

 

< 중간고사 범위 끝! :) >