Swashbuckle 이용시 알아두면 좋을 소소한 팁 #1 Swashbuckle 이용시 알아두면 좋을 소소한 팁 #2 Swashbuckle 이용시 알아두면 좋을 소소한 팁 #3 지난 포스트에 이어 이 포스트에서는 Swashbuckle 라이브러리를 이용해서 Swagger 문서가 XML 문서를 다룰 수 있게 도와주는 확장 기능에 대해 알아본다. 이 포스트에 사용된 코드 샘플은 이곳에서 확인할 수 있다. 참고사항 이 포스트에 사용한 애플리케이션은 []

Swashbuckle 이용시 알아두면 좋을 소소한 팁 #1 Swashbuckle 이용시 알아두면 좋을 소소한 팁 #2 Swashbuckle 이용시 알아두면 좋을 소소한 팁 #3 지난 포스트에 이어 이 포스트에서도 Swashbuckle 라이브러리를 이용해서 Swagger 문서를 작성할 경우 필요한 확장 기능에 대해 알아본다. 이 포스트에 사용된 코드 샘플은 이곳에서 확인할 수 있다. 참고사항 이 포스트에 사용한 애플리케이션은 아래 스펙으로 만들어졌다: []

Swashbuckle 이용시 알아두면 좋을 소소한 팁 #1 Swashbuckle 이용시 알아두면 좋을 소소한 팁 #2 Swashbuckle 이용시 알아두면 좋을 소소한 팁 #3 ASP.NET Web API 애플리케이션을 개발하면 빠지지 않는 것이 바로 Swagger 문서 생성이다. Swashbuckle을 사용하면 이 작업을 굉장히 손쉽게 할 수 있다. 하지만, 이 라이브러리는 Swagger 스펙을 100% 구현하지 않았다. 필수적으로 쓰여야 하는 부분들을 제외하고는 []

얼마전 Azure Functions(애저 펑션)에 Swagger로 알려진 OpenAPI 지원 기능이 추가됐다. 애저 펑션을 API로 사용할 경우 굉장히 유용한 기능인데, 이 포스트에서는 어떻게 Swagger를 연동시킬 수 있는지 간단하게 알아보기로 한다. 이 포스트에 쓰인 샘플 코드는 이곳에서 확인할 수 있다. 샘플 애저 펑션 인스턴스 우선 애저 펑션 인스턴스를 생성해서 간단한 펑션을 두 개 만들어 보도록 한다. 하나는 CreateProduct이고, []

마이크로서비스 아키텍처를 이용해 서비스를 운영하게 되면 서비스간 메시지 교환은 API를 이용한다. 이런 API를 개발할 때 두 가지 접근 방법을 생각할 수 있는데, 하나는 모델 우선 (Model First) 개발 방식이고, 다른 하나는 설계 우선 (Design First) 개발 방식이다. 보통은 후자의 설계 우선 개발 방식을 채택하는데, 이의 또 다른 표현에는 스펙 주도 개발 (Spec-Driven Development; SDD)이 있다. []

Azure에서 제공하는 강력한 기능들 중 하나가 바로 API 매니지먼트 (APIM)이다. 마이크로서비스 아키텍처(MSA)를 구현한다거나, 혹은 여러 API를 운영한다면 API의 사용자 입장에서는 여러개의 endpoint 보다는 하나의 통합된 endpoint가 있을 때 훨씬 더 사용하기 편리할 것이다. 그렇다고 해서 수많은 API 애플리케이션을 하나로 통합해서 endpoint를 하나로 운영하는 것은 더더욱 무리일텐데, 이럴 때 사용할 수 있는 방법들중 하나가 바로 이 []

  • 1
  • 2