1. 첫 번째 학습 내용: 카훗 퀴즈

Q. 메모리에서 지역 변수와 매개변수가 저장되는 영역은? Stack 영역

Heap 영역에 저장되는 것들? Reference semantics는 stack에는 reference인 주소값을 할당하고, 실질적인 데이터는 heap에 할당합니다. 대표적으로 class가 있으며 function 또한 reference semantics입니다.

<동적 할당> 키워드 중요 ⭐️

Stack & Heap
Stack은 LIFO(Last In First Out)의 단순한 구조로 메모리 할당과 해제가 편리합니다. Stack은 Stack Pointer를 사용하여 할당・해제를 처리합니다. Stack은 단순한 구조를 가진만큼 시간복잡도는 O(1)으로 속도가 매우 빠릅니다.
Heap은 stack보다 더 복잡한 구조를 가지고 있습니다. Heap은 Stack보다 dynamic한 할당 방법을 사용하는데, Heap 영역에서 사용하지 않은 블록을 찾아서 메모리 할당을 처리합니다. 할당을 해제하기 위해서는 해당 메모리를 적절한 위치로 다시 삽입합니다. 여러 thread가 동시에 Heap에 메모리를 할당할 수 있기 때문에 locking 또는 기타 동기화 메커니즘을 사용하여 무결성을 보호해야합니다.
위 특징들을 살펴보면 알 수 있듯이, stack은 heap보다 비용이 더 적게 들어가며, 속도가 더 빠른 할당 방법입니다.

[Swift] 스위프트 성능 이해하기 (1) - struct와 class의 성능 차이

Q. Swift에서 지원하는 Method dispatch 방식은?

• Static Dispatch
• Table Dispatch
• Message Dispatch
• Direct Dispatch

Q. 애니메이션 제공 기본 클래스 UIView

Q. UIView의 애니메이션 메서드는 비동기적으로 동작한다 (X)

클로저 던져줌

다른거 하면서 같이 진행됨

Q. UIView의 애니메이션을 동적으로 편집할 수 있도록 도와주는 클래스? UIViewPropertyAnimator

2. 두 번째 학습 내용: Http(s)

Http(s)
request는 이미 던지는 순간 결정됨
수정이 안됨
→ 연결을 하고 있는 상태가 아님 !
→ response랑 공을 주고 받는 거라고 생각하면 됨

response가 돌아오는 순간 통신 단절됨

request와 response의 싸이클을 이해하면 됨
연결되있는 상태가 아니라 ‘던진다’의 개념!

• 어디에 값을 쓰냐에 대한 차이
  Get은 ‘헤더’에다가 데이타를 써서 던짐
  Post, put, patch는 ‘바디’에 데이타를 씀

get은 자원을 가져올 때
Post, put, patch는 자원을 관리 (수정, 생성)할 때
delete는 자원을 삭제할 때 사용

Put 자원을 수정 (자원의 전체 또는 해당 자원 수정으로 별도의 수정이 발생할 때)
Patch 자원을 수정 (자원 내에서 특정 하나의 값만 수정할 때)

Headers

• Content-type에 따른 내용?
  http 프로토콜이 약속
  컨텐츠 타입은 데이터를 어떤 형태로 서버에 전달하는지 알려주는 것
  여러 형태의 컨텐츠 타입이 존재하는데
  그 타입에 따라서 데이터 형태가 다름

e.g. 멀티파트 폼 데이타 타입의 컨텐츠 타입

헤더 → 주소
호스트 도메인

멀티파트 폼 데이타 → 파일 업로드하거나 회원가입 폼 할때 쓰임
(지금은 보통 attachment 파일이 존재할 때 사용됨)

Boundary = 포스트맨에서 자동으로 생성됨 (신경쓰지 않아도 됨)
Content-length: request 전체의 크기

밑에는 body 영역

• 컨텐츠 타입에 따른 형식이 다르다보니
  이 타입을 명시하지 않으면
  서버에서는 이거를 어떻게 디코딩해야 할지 모름!

가장 많이 사용되는 형식은
Application/json
Multipart/form-date

• Body와 query의 차이점
  바디는 서버가 구현되어 있지 않으면 읽을수가 없음
  쿼리는 그냥 읽을 수 있음 (주소 URL에 포함돼있기 때문)
  → URL에 쿼리가 노출돼있음

바디는 get, delete에서는 사용 못함
query는 get과 delete에서도 쓸 수 있음

용도 자체가 리스트를 검색하거나 무언가를 찾고자 할 때
내가 어떤 검색 조건에 대한 키워드를 제공할꺼야 → 쿼리

바디 같은 경우엔 많은 양의 값을 보낼 수 있다보니까
작성이나 수정같은 대용량 데이터를 보내는게 용이함

Why? 주소창에 파일을 던질 순 없으니까
바디에 넣어서 보내야 하니까

결국에는 내가 요청할 값의 형태를 쿼리를 통해 표현하거나
작성하거나 수정할 내용은 바디를 통해 표현

굳이 나눈 이유는
http 명세의 한계상
Url 쿼리의 길이가 제한적임

바디가 많이 큼
데이타의 유실을 막기 위해서는 바디에 감싸서 보냄

결론)
메서드 지정
헤더에 컨텐츠 타입 명시
바디나 쿼리에 사용할 데이타를 담아서
키와 함께 서버에 전달함

서버에서는 값의 키와 밸류를 확인해서
검색된 데이타를 만들어서
response를 보내줌

request랑 response랑 대동소이함
리퀘스트에 있는 것이 리스폰스에 있음

리스폰스에서는 status 키워드를 살펴봐야 함
status는 응답에 대한 상태를 한눈에 알아볼 수 있게끔 알려 줌

에러 났을때는 400 이상의 코드를 던져줄거임

400번대 → 리퀘스트에 문제가 있을 때
500번대 → 리퀘스트 정상적이지만 서버 쪽에서 처리하다가 에러가 났을 때

502랑 504는 성격이 다름

어쩔떈 오류를 200으로도 표현함

response에도 body가 있어서
바디 안에 에러코드랑 성공 실패 여부 담아서 주는건데
이렇게 주면
바디를 컨텐츠 타입이 json으로 왔으면
스위프트에서는 내 요청이 성공했는지 알려면
파싱해야함

바디를 status 만으로는 알 수 없음
= 에러처리 할 수 없음
안티패턴이라서 요새는 사용하지 않음 ?

201
비동기 프로그래밍
요새는 발행되는 시점이 달라짐
응답이 돌아왔을 때 컨텐츠가 없을 가능성이 큼

202
비동기 프로세스에서 사용되는데
주문은 접수됐다
지금 당장 가용할 수 있는 리소스는 없지만
너가 요청한 리퀘스트가 정상적으로 접수돼서
서버에서는 동작하고 있어

204 되게 많이 쓰임 ⭐️⭐️⭐️
어디 접속을 해서 검색하려는데
리스트, 아티클 검색함
근데 검색 결과가 없음
= 컨텐츠가 없음
→ no content라고 응답
(오류가 아님)

200번대는 리퀘스트가 정상 요청일 때 씀
200번대가 ok라는 것만 인지하면 됨

200, 201, 202, 204는 현업에서 많이 씀
204는 바디가 없음 (값을 전달할 수 있게 바디가 제거됨)

200번대 나머지는 다 쓰는 팀은 잘 없음

400번대 → 리퀘스트가 부합하지 않음
(에러라고 보기엔 애매하고 warning 정도로 보면 됨)

서버에서 네가 무슨 얘기 하는줄 알겠는데 해줄 순 없어 이런 의미

400 post, put, patch 상황에서 바디 값이 잘못됐을 때 많이 나타남
디코드 자체가 잘못됐을 때 나는 오류
보내준 바디의 값이 잘못돼서 디코드 자체가 안됐을 때

Todo task를 작성하는 URL도 요청을 보냈는데
바디에 회원 정보를 담아서 보내면 디코드를 할 수 없음?

401 인증 실패
사용자된 로그인 정보 식별하거나
사용자의 인증, 권한 식별 상태 확인

상품 상세 페이지에서 수정 요청할 수 없음
(관리자가 아니면)

앱들 로그인하고 나서
계속 로그인되있는 앱은
Access token 인증 연장하는 것

401 코드가 들어오면
어플리케이션 백단에서는 Access token을 갱신함
= 인증 연장

403은 특수한 에러
403, 404, 405는 클라이언트 (개발자) fault
접근하면 안되는 URL로 접근을 했거나
존재하지 않는 요청
405는 메서드가 post만 쓰는 url에 get을 던짐

404 같은 경우에는 오타나 주소 자체를 잘못 썼을 때
서버에서도 대답해주지 않음

405 리퀘스트 메서드 잘못 작성했을 때 나는 에러

409 복수 사용자가 하나의 리소스에 접근했을 때
동시에 수정해서 오류가 나거나
정상적인 행동을 하지 않을 때
요청이 서버쪽이랑 충돌이 나는데?

409는 많이 쓰이지는 않음
동기화된 자원에 접속할 때

502 네트워크 설정 자체가 잘못돼있을 때

Rest & Resful Api

REST API(RESTful API, 레스트풀 API)란 - 서버, 구현, 사용법

서버와 클라이언트간의 HTTP 범용 크루?

• Uniform Interface
  = 일관된 인터페이스
  URI나 자원을 표현하는데 사용되는 규칙

일관되지 않은 규칙을 만나면 힘들어짐
Uniform interface 안에 URI 다루는 개념이 있음

Todo task 목록을 가져올 때
뭘 쓸까?
get으로 테스크를 가져와야 함

사용자의 야곰의 테스크
Users/yagom/task
→ 사용자 중에서도 야곰이 가지고 있는 테스크라는 뜻

Restful api에서는 자원의 위치 (= URI)를 표시함

• Stateless
  서버에서는 여러분이 누군지 알 수 있는 방법이 없음
  Access token = 나를 증명하기 위해 사용
  요청의 상태를 들고있지 않음?

• Client-Sever
  클라이언트와 서버의 역할이 명확히 구분돼야 함

• Cacheable
  재사용이 가능해야 한다

• Layered System
  뒷단의 구조 알 필요 없이
  동일한 결과 받을 수 있어야 한다

• Self-Descriptiveness
  핵심: 요청 스스로가 자신을 설명할 수 있어야 한다
  = 명세를 별도의 문서 없이 알 수 있어야 한다

html로 통신 안함
보통 json 사용함

Hateoas
Hateoas는 API를 좀 더 쓰기 쉽게 해주는 요소

• WebLink
• HAL

Todo task라는 클래스는
수정도 할 수 있고
삭제도 할 수 있음

이 태스크 하나에 대해서 어떤 행위를 할 수 있는지 잘 모름

link라는 키워드를 통해서
약속된 표현 형태를 받게 돼있음

나 자신을 가져오려면 href라는 아이디를 요청해야해
나를 수정하려면 메소드를 patch로 수정해줘

An overview of HTTP - HTTP | MDN

HTTP request methods - HTTP | MDN

HTTP response status codes - HTTP | MDN

• Response

  • status

    • 200, 201, 202, 204 → OK
    • 400, 401, 403, 404, 405, 406, 409, 429 → Client Side Fault
    • 500, 502, 504 → Server Side Fault

  • headers

    • Content-Type

  • body

    An overview of HTTP - HTTP | MDN

    HTTP request methods - HTTP | MDN

    HTTP response status codes - HTTP | MDN

    Rest & Restful Api

    http 와 차이점이 모지?

  • Uniform Interface

    • 일관성있는 인터페이스로 URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일.
    • HTTP 표준 프로토콜에만 따른다면 모든 플랫폼(특정 OS나 특정 언어에 종속된 것이 아닌)에서 사용이 가능하다.

  • Stateless

    • HTTP 프로토콜이 Stateless Protocol인 것과 마찬가지로 REST도 무상태성을 갖는다.
    • 클라이언트의 세션과 쿠키같은 컨텍스트를 서버에 저장하지 않으므로 서버 구현이 단순해진다.
    • 클라이언트의 요청을 각각 별개의 것으로 인식하며 단순 처리하게 처리만 하면 된다.

  • Client-Sever

    • 자원이 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트로 클라이언트-서버 구조를 갖는다.
    • REST 서버는 API를 제공하고 클라이언트는 사용자 인증, 컨텍스트(세션, 로그인 정보 등)을 직접 관리한다.
    • 클라이언트와 서버의 역할이 구분되어 개발 내용이 명확해지고 의존성이 줄어든다.

  • Cacheable

    • 웹 표준을 따라 웹의 인프라를 사용할 수 있으므로 캐싱 기능을 적용할 수 있다.

    • HTTP에서 사용하는 Last-Modified나 E-Tag를 사용해 구현할 수 있다.

    • 일반적인 서비스에서 조회 기능이 많이 사용된다는 점에서 캐싱 기능이 용량과 성능면에서 이점이 있다.

    • 응답시간이 빨라지고 트랜잭션이 발생하지 않아 대용량 요청을 효율적으로 처리한다.

      → 캐시 : 자주 사용하는 문서의 사본을 자동으로 보관하여 웹 요청이 캐시에 도착할 때 로컬 사본이 존재하면 문서가 서버쪽이 아닌 캐시로부터 제공된다.

  • Layered System

    • 클라이언트와 서버가 분리되어 중간에 프록시 서버, 로드 밸런싱, 암호화 계층 등 중간매체를 사용해 자유도를 높일 수 있다.
    • 클라이언트는 API만 호출하므로 직접 통신하는 것 인지 중간 서버와 통신하는지 알 수 없다. ( 알 필요 없다?)

  • Self-Descriptiveness (핵심) → 자기서술적 메시지?
    - JSON형태의 메시지를 통해 내용을 직관적으로 이해할 수 있다.
    - Rest API 메시지 만으로 그 요청이 어떤 행위인지 알 수 있는 자체 표현 구조로 되어있다.

    [ Network ] REST란? / Rest API와 Restful API의 차이점 / REST 규칙

    HTTP API vs REST API - 인프런 | 질문 & 답변

    REST - 위키백과, 우리 모두의 백과사전

    [ Network ] REST란? / Rest API와 Restful API의 차이점 / REST 규칙

    https://www.youtube.com/watch?v=iOueE9AXDQQ

• REST API란,
  HTTP요청을 보낼 때 어떤 URI에 어떤 메소드를 사용할지 개발자들 사이에 널리 지켜지는 약속!

문제점/고민한점 → 해결방안

text field input 저장하는 법

How to store input from TextField into an array of Strings in Swift?

Datepicker value String값으로 저장하는 법

How to get a String value from the UIDatePicker

→ 강경 코드 참고 예정..

배열안의 배열에 저장하는 법

Add element to a complex nested collection in swift

할일을 배열안의 배열로 임시 데이터로 넣어줌

var todoLists = [[할일, 제목, 날짜], [할일, 제목, 날짜], [할일, 제목, 날짜] ...]

그래서 새로운 테스크가 추가됐을 때 그냥 마지막 순서에 배열을 하나 더 넣어주면 되지 않을까...?
했는데 결국 방법을 못 찾았다 ^.ㅠ

이 방법은 비효율적이란 생각이 들었음 😣
다른 조들도 보니 모두 할일을 인스턴스로 만들어서 배열에 넣어주고 있음
방법을 바꾸기로 함 !