아래 내용은 개인적인 생각임을 감안해주세요

2022년 4월 20일 내용 추가
 

원글: https://news.hada.io/topic?id=6121

일관성 유지 : URL/헤더/인증/상태코드..
ISO8601 UTC 날짜 포맷 사용
Public Endpoint만 인증 예외. 나머지는 모두 인증 필수
헬스 체크 Endpoint 제공
API 버저닝
API 키 인증 적용
합리적인 HTTP 상태코드 와 메소드 사용
각 Endpoint에 자체만으로 설명 가능한 간단한 이름을 사용
표준 에러 응답 사용
POST에서 생성된 자원을 리턴
PUT 대신 PATCH
최대한 구체적으로
Pagination 사용
각 자원을 확장 가능하게 (expand 등의 쿼리 파람을 줘서 추가 정보도 리턴 가능하게 설계)

원글: https://news.hada.io/topic?id=5823

- "AWS가 15년간 배운 좋은 API를 만드는 6가지 원칙" 에 대한 메모
1. API는 영원하다!
2. 하위 호환성을 지켜주세요.
3. 고객 사용 사례에서 거꾸로 만드세요.
4. 오류가 명시적인 API를 만드세요.
5. 바로 목적과 사용법을 이해할 수 있는 API를 만드세요.
6. 구현 세부 정보는 누출되지 않게 신경을 쓰세요.

- 초기 API 설계에서 실수하는 것
- Smithy를 통한 확장성 높은 API 만들기

몇년간 엄청나게 많은 API를 개발했는데, 그 중에서 RESTful API 설계에 대한 몇가지 개인적인 생각을 메모로 남겨봅니다.

 - 참고로, 인프라 셋팅/운영, 개발 실무, 개발팀 셋팅 및 SW개발 프로세스 수립, 많은 사용처에게 API 제공 등의 업무를 겪어서 단순 기술적인 부분이 아니라 조직원, 고객(?)에 대한 고민도 일부 반영된 내용입니다.

1. RESTful API를 완벽히 적용하기는 실무에서 어렵습니다.
   1. API 사용쪽에서 방화벽 등의 인프라에 DELETE, PUT이 막혀서 사용이 불가능할 수 있습니다.
   2. 웹 기술에 익숙하지 않는 API 사용자(개발자)가 생각보다 많습니다.(그나마 최근 몇년 사이에 조금 좋아진듯합니다.)
      1. status 200이 정상임을 모르는 경우도 많음.. ;;)
      2. status 200일 경우에만 body를 파싱하도록 개발하는 개발자도 많음
         1. ex) 400응답일때 파라미터 xx가 오류라고 응답하면 에러코드나 설명을 처리할줄 모름
            
            
2. POST와 GET 위주로 사용하는게 좋습니다.
   1. 데이터(리소스) 변경이 발생하는 경우는 POST를 사용
   2. 단순 질의(CQRS패턴의 질의? 같은 느낌인가..)는 GET을 사용
      1. 단, 보안이 중요하면 질의 형태도 POST를 사용
         1. 예) API URL을 메신저에 공유하면 각 메신저 개발사의 봇들이 호출 -> API 개발자가 실수로 인증 기능을 적용 안해둠 -> GET API가 작동->그런데 그 API가 유저 탈퇴 처리하는 운영기능 API였다면???
   3. DELETE와 같은 추가 메소드를 사용하지 못하는 문제는 URL을 잘 정의해서 회피/의도를 노출
      1. 예) URL path 마지막에 의도록 노출(ex. /블라블라/cancel)
         
         
3. 이름을 잘 명명해야합니다.
   1. 이미 한번 배포되어 사용되면 바꾸기가 쉽지 않음
      1. 예)API URL에 오타가 있으면 서비스 종료까지 그대로 사용하게 됨(API 사용자가 생각보다 잘 수정해주지 않습니다.)
         
         
4. API는 일관성을 가져야하며 사용자(API 사용 개발자)가 적용하기 쉬워야합니다.
   
   
5. 지금은 필요하지 않아도 버전을 명시해야 하고 2depth에는 세부 기능의 대표 명사를 사용하는게 좋습니다.
   1. 서비스가 대박이 나서 트래픽이 늘어나면, URL path를 이용해서라도 트래픽을 분산, 또는 MSA로 적용 용이, 달리는 자동차 바뀌 교체 용이
      1. 예) 도메인/v1/member/

또 생각나면 추가로 작성하겠습니다.

1. 필요 플러그인
   1. build user vars(링크)
2. 사용 방법
   1. 빌드 환경에서 "Set jenkins user build variables" 활성화
   2. 이후 변수 접근해서 사용 가능
   3. 예)
      
      

nginx에서 아래 내용 추가

proxy_pass_header  Server;

지난주 금요일에 if kakao day 2에 다녀옴

구글에 검색하면 다른분이 잘 정리해주신게 후기 내용의 정리는 pass

인상 깊었던 내용 중 하나가 '쇼핑 쪽 es' 인덱싱하는 부분이 몇년전 내가 만들어둔 커뮤니티 사이트와 거의 동일(당시 es 2.x가 최신이라서 해당 버전으로 사용했지만..)

full index, 증분 index, pk대상, update_at 사용 등등. 사람 생각은 비슷비슷하다는 생각이 들었음

 - https://if.kakao.com/program?sessionId=aea80282-879c-4af8-9e88-86a27c454d4b

P.s. 입구 앞쪽에 쉴 수 있는 공간에 의자(?)가 플라스틱박스로 불편함. 네이버 데뷰처럼 좀 신경썻으면 좋았을것 같음

https://ofbiz.apache.org/

Apache OFBiz is a suite of business applications flexible enough to be used across any industry. A common architecture allows developers to easily extend or enhance it to create custom features.

추가

• AWS CloudFront를 사용할때 http header를 이용해서 특정 국가를 nginx를 이용해서 차단하고 싶을때

if ($http_cloudfront_viewer_country = "CN") {
  return 403;
}

rate limit에 해당될때 json으로 리턴하고 싶을때 샘플

error_page 429 /429.json;
    location /429.json {
        add_header 'Content-Type' 'application/json charset=UTF-8';
        return 429 '{"success":false, "errorCd":"RATE_LIMITED","msg":"Too Many Requests(rate limit nginx)"}';
    }

중국쪽 봇 등으로 짜증날때 nginx로 전체 인입허용 트래픽을 빠르게 조절할때 사용할 목적으로 간단하게 메모해둡니다.

 - 아래 내용은 추후 복/붙 가능한 형태로 좀 수정해둘 예정

http블럭에

limit_req_zone $binary_remote_addr zone=myLimit:10m rate=10r/s;

location 블럭안에

limit_req zone=myLimit burst=5 nodelay;

limit_req_zone

예) limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

• context: http
• key: 요청량 제한 단위 지정 (예. server_name, remote_addr, uri 등) $server_name을 지정하면 모든 트래픽에 대해 요청량을 제한함
• zone: 요청량 기록을 위해 사용하는 Key:Value 가 저장될 Shared Memory 크기.
  • 주의: IP 단위로 요청량을 제한 할경우 충분히 큰 값을 설정하지 않으면 메모리 부족 발생할 때 모두 503에러
• rate: 허용할 request per second 값으로 10r/s를 설정하면 NGINX는 100ms 마다 1개의 요청을 처리

limit_req 

예) limit_req zone=mylimit burst=10 nodelay;

• context: http > server > location
• burst: key에 설정한 요청량보다 초과된 요청량을 수용하는 크기로 대기큐.
  • rate를 10 rps 로 설정했을 때 100ms 안에 10개의 요청이 들어오면 1개만 처리되고 나머지 9개의 요청은 503 에러가 발생하는 데 이 때 해당 에러를 완화하기 위해서 burst옵션을 사용
  • nodelay: 요청이 rps 에 지정된 시간보다 빨리 처리되었을 때 rps에서 지정한 시간을 기다리지 않고 burst queue에 있는 다음 요청을 바로 처리. 해당 옵션을 사용하지 않는다면 burst queue가 비워질 때까지 새로운 요청은 모두 503 응답

limit_req_dry_run 

• on: 실제로 제한은 하지 않고 로그를 남김
  • 꼭 해당 기능을 이용해서 라이브 환경의 적절한 수치를 확인하고 적용하는게 좋음
    • 로그에 $limit_req_status 설정 추가 필요

기타

 - 제한에서 제외할 IP설정 방법

geo $apply_limit {
    default         $binary_remote_addr;
    10.10.0.0/16    '';                   # 내부 네트워크 대역 10.10.*.* 은 access limit 사용안함
    211.33.188.246  '';                   # 외부의 특정 IP 211.33.188.246 는 access limit 사용안함
}

...
...

limit_req_zone $apply_limit zone=depend_rate_limit:10m rate=10r/s;

...

geo 모듈을 사용해서 client ip 를 확인해서 $apply_limit 이라는 변수를 새롭게 할당했다. 10.10.. 대역 이거나, (내부 네트워크 대역인 경우), 외부의 특정 211.33.188.246 인 경우에는 빈값이 지정된다.

이렇게 하고 나서 limit_req_zone 에 정의한 $apply_limit 변수를 사용하면, 예외로한 IP 에 대해서는 접속제한이 동작하지 않는다.

참고 링크

 - https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-access-proxied-http/

 - https://bactoria.github.io/2020/01/19/Nginx%EC%9D%98-limit_req-%EB%AA%A8%EB%93%88-%EC%82%AC%EC%9A%A9%EA%B8%B0/

 - https://findstar.pe.kr/2018/06/24/nginx-rate-limiting/

 - https://serverfault.com/questions/177461/how-to-rate-limit-in-nginx-but-including-excluding-certain-ip-addresses