The document discusses the need for more reusable APIs and outlines 10 things API developers should stop doing, including mapping semantics to protocols instead of messages, hiding update and query rules in documentation, and requiring clients to recode and redeploy at random. It argues that APIs should map semantics to messages, use inline hypermedia controls, provide SDKs when needed, share message models rather than object models, describe services abstractly, put workflow in messages, avoid breaking changes, and distribute storage and execution rather than relying on single points of failure. The document concludes that making these changes to follow best practices for reusable APIs is not complicated, though some aspects may be hard.
스타트업에 가장 필요한 것은? 바로 스피드입니다.
오픈 API는 스타트업이 스피드업할 수 있는 유용한 도구라 할 수 있습니다.
품질 좋은 오픈 API,
즉 가이드나 플랫폼 SDK까지 잘 갖추고 있는 오픈 API를 활용한다면
더욱더 빠르게 서비스를 개발해 혁신을 가속화할 수 있을 것입니다.
5월 10일, 스타트업의 스피드업을 도울 네이버 오픈 API를 소개합니다.
스타트업에 가장 필요한 것은? 바로 스피드입니다.
오픈 API는 스타트업이 스피드업할 수 있는 유용한 도구라 할 수 있습니다.
품질 좋은 오픈 API,
즉 가이드나 플랫폼 SDK까지 잘 갖추고 있는 오픈 API를 활용한다면
더욱더 빠르게 서비스를 개발해 혁신을 가속화할 수 있을 것입니다.
5월 10일, 스타트업의 스피드업을 도울 네이버 오픈 API를 소개합니다.
This document discusses techniques for improving global web performance and content delivery networks (CDNs). It begins by explaining how internet speeds vary globally and within Korea. It then discusses how CDNs work by caching content at the edge to reduce latency. Both national and global CDNs are described, with global CDNs having points of presence around the world. Metrics for measuring website performance like waterfall charts are also presented. Methods for optimizing websites through techniques like initializing TCP connections and front-end optimizations are then covered. The document concludes by discussing some advanced topics like mobile network latency.
MongoDB: Scaling write performance | Devon 2012Daum DNA
This document discusses strategies for scaling write performance in MongoDB. It begins by noting that while MongoDB is easy to install and use for simple data models, scaling write performance becomes challenging, especially with secondary indexes. Maintaining high insert throughput requires careful consideration of the shard key to ensure even data distribution and avoid overloading indexes. Techniques discussed include partitioning collections by time, upgrading hardware with more RAM and IOPS, and choosing a low-cardinality hash prefix plus sequential field as the shard key. The key lessons are to understand how indexes impact performance, test shard key choices thoroughly, and recognize that linear scalability requires significant hardware resources.