쉐도잉 연습: 2.2k - 영상으로 영어 말하기 배우기

연습 모드 선택

각 모드는 전체 화면 연습실로 열립니다.

129 문장

문장이 너무 짧거나 길면 Edit를 눌러 조정하세요.

Hey friends, welcome back to the channel.

So when designing an API,

it's easy to think about the happy path of your application.

But if you want to build a robust application and keep your users happy,

then you need to consider the unhappy path as well.

What happens if your user's internet connection cuts out just after making a request?

Or maybe your server's struggling under load and the client times out before it can receive a response?

Usually errors are handled by the client by doing retries.

If there's an error or the request times out,

then the client will retry a number of times,

either automatically or by a frustrated user hitting that submit button.

If the user sends multiple requests to the server and more than one of them gets through,

then you'll likely end up with duplicates on your end.

Depending on the application, this might not be a big deal.

If the user is just writing a comment on a blog post or reviewing a product,

then it's not the end of the world if they end up with multiple posts.

But what if they're sending an email?

Is it okay for the recipients to receive multiple copies of the same email?

What if they were buying something online?

Would the customer be happy if they got charged twice or maybe even 10 times for the same product.

This is where idempotency comes in but what does it actually mean?

If we have a look at the internet standards it says the following.

A request method is considered idempotent

if the intended effect on the server of multiple identical requests with

that method is the same as the effect for a single such request.

So if we call an API multiple times with the same request then it's considered idempotent

if it has the same effect on the server as if we had only called it once.

Now let's have a look at the most common methods and see whether they're idempotent or not.

The get method is read only,

it doesn't affect the server in any way.

Nothing gets created or updated so we can call the get method multiple times without it having any adverse effects.

So a get method is always idempotent.

With a put request we're going to be performing updates.

So let's say we're updating a user's email address.

No matter how many times we call this method we should always get the same response

and the user's details are always going to get updated to the same thing.

So a put request is always idempotent as well.

With a post request we're creating something on the server.

So if we call this method multiple times then we should expect to get multiple copies of the same thing.

Or in some cases we might get an error if we're trying to create something that can only be one of.

For example if we're trying to create a new user with a post request.

Then the first request will go through but a second request for the same username will fail because the user already exists.

Technically this is still idempotent but it's not a very nice experience for the user user.

Let's say when they make their first request they then have an internet connection failure and therefore don't get a response.

When they try and retry it will tell them

that the username order exists but in fact it was their first request that created that user.

If we take the example of making a payment then generally

there aren't any unique identifiers on a payment like there are with creating a user.

This is what we typically might send through on a platform like Stripe if someone's buying something for $20.

However there is nothing unique about this request that links it to a particular purchase.

If a payment platform receives two of these then it'll just think it's two separate payments and charge the customer twice

which is not what we want.

So post requests are generally not idempotent.

With patch requests it depends on how you use them.

If you're just using it to update an email address of a user then that could be considered idempotent.

However you can also use a patch request to do things like copy,

move, add and remove and therefore it's not considered idempotent.

Finally we have the delete method which deletes an object on the server.

If you run delete multiple times it's going to have the same effect on the server as

if you'd only run it once.

Sure the second time you might run it you might get an error

but the actual server doesn't change its state therefore delete is also considered to be idempotent.

In the cases where you're making a payment or some other Crisco operation

that needs to happen exactly once then you need to make those other methods such as post and patch idempotent as well.

The only way that you can really do this is to have some form of unique identifier.

That way you can distinguish that request from some otherwise identical requests.

You may have something like this already in place.

Let's go back to the payment analogy.

Let's say you have a saved basket of items and that basket has an ID.

That ID is therefore unique to that order and you could use that ID for the idempotency key.

Another option is to hash the body of the request.

However if you're doing this you need to make sure

that there's no reason for that person to ever send exactly the same request.

There should be something about the combination of fields in the request that makes it unique.

For example if someone orders a Spongebob beach towel

and then 30 seconds later orders another Spongebob beach towel you don't know that that's a duplicate order.

They might just really like Spongebob.

Generally the way this is normally done is to add an idempotency key to a header.

Stripe for example have a header called idempotency-key but really this could be anything.

So you now have some form of key that makes this request unique.

However with a user supplied key you can't guarantee that it's going to be globally unique.

The user could send you the same key as another user or even the same key from multiple endpoints.

So it's important you always combine

that user supply key with something like a user id as well as the API path that's being used.

To implement idempotency you need to store your combined idempotency key along with the successful response that you send to the user.

If a request with the same idempotency key comes in instead of actually performing the operation,

you just send them back a response that you sent out before.

As far as the user is concerned,

the operation was successful and they don't need to know that you're sending out a previous response.

Typically this is done using some form of key value storage such as Redis or DynamoDB.

Technically you could store your idempotency keys in an in-memory storage such as a dictionary.

However this won't work if you have multiple copies of your API running behind the load balancer,

as each API won't be able to see the keys in the other copies.

You will also lose your idempotency keys whenever you have to restart your application.

This is why we don't store them in memory.

So when a request comes in you need to first check to see whether

that idempotency key that's been sent is in your storage.

And if it is then you just send back the response that you have stored.

If the idempotency key doesn't exist then you carry on with the normal operation

100

and if it's successful then you store the idempotency key along with the response before sending it back to the user.

101

How long you store your idempotency keys for really depends on the application.

102

If you have idempotency enabled just to protect yourself from a

103

user clicking on something multiple times then you might only need to store them for say 10 minutes.

104

But if you have some sort of retry mechanism in place then you might need to store them for longer.

105

Typically we store idempotency keys for anywhere between 24 and 48 hours

106

but you need to check with your application and see if it makes sense to store them for longer.

107

If you are using something like redis

108

or dynamo db to store your keys then you can use the time to live

109

or ttl so that your keys are automatically deleted for you.

110

You may also want to consider idempotency validation in your API.

111

If a request comes in with the same idempotency key from

112

the same user for the same endpoint then we're just going to assume

113

that that's the same request and send them out the same response.

114

However there is a chance

115

that the user has just used the same idempotency key by mistake and the request body is actually very different.

116

If you need to protect yourself against this sort of scenario then you can take a hash of the request

117

and store that alongside the idempotency key and then

118

when the request comes in you can check to see whether it matches the hash as well

119

and if it doesn't return an error to the user.

120

If you want to implement this in the .NET Core API then you can make use of the distributed caching library

121

and then store your keys in redis and then you can create a filter

122

which you can then add to each of the endpoints where

123

you want idempotency to make this even easier there is a new get package called idempotent api

124

that does all the heavy lifting for you

125

if you want to support this channel

126

and also get access to the code shown in my videos

127

and you can subscribe on patreon patreon members also get access

128

to exclusive content from me as well as a private discord community and generous discounts to my courses once I release them.

129

Thank you for watching this video and I'll hopefully see you in the next one.

앱 다운로드

유창하게 말하는 데 필요한 모든 것

AI 발음 평가문장마다 점수 확인

IPA 발음 연습모든 소리 마스터

단어 학습나만의 단어장 만들기

단어 게임놀면서 외우기

QR 스캔

Download on theApp Store Get it onGoogle Play

FOR YOU

왜 이 영상을 통해 말하기 연습을 해야 할까요?

이번 유튜브 영어 공부 영상은 API 설계와 관련된 주제를 다루고 있어, 기술적 대화를 영어로 자연스럽게 하는 연습에 큰 도움이 됩니다. 이 영상은 클라이언트와 서버 간의 소통 방식을 설명하고, 오류 처리와 같은 실용적인 상황을 제시합니다. 이러한 내용은 특히 IT 분야에서 일하거나 공부하는 분들에게 유용하며, 해당 주제를 영어로 소통할 때 필요한 표현과 문장을 익힐 수 있습니다.

맥락 속의 문법과 표현

영상 속에서 사용된 몇 가지 주요 문법 구조와 표현을 살펴보겠습니다:

“What happens if…” - 이 표현은 가정법을 사용하는 예로, 다양한 상황을 상정하며 대화를 이끌어가는 데 유용합니다.
“Consider the unhappy path” - 'unhappy path'라는 표현은 소프트웨어 개발 맥락에서 흔히 사용되는 용어로, 예상치 못한 상황을 고려할 때 사용됩니다.
“The same effect on the server” - 'the same effect'는 비교 구조를 사용하여 여러 요청의 결과가 동일하다는 점을 강조하는 표현입니다.
“Is it okay for the recipients…” - 질문 형태의 이 문장은 소통에서 청중의 반응을 고려하는 방법입니다.

이러한 문법과 표현들을 영어 쉐도잉 활동에 활용하면, 자연스러운 말하기 능력을 키울 수 있습니다.

일반적인 발음 함정

영상에서 특히 주의해야 할 발음 함정과 단어들을 살펴보겠습니다:

“Idempotent” - 이 단어는 발음하기 어려운 단어 중 하나로, '아이덴포턴트'라고 발음됩니다. 정확한 발음 연습이 필요합니다.
“Duplicate” - '듀플리케이트'라는 발음 또한 주의가 필요하며, 특히 'u' 발음을 분명히 해야 합니다.
“Request”와 “Response” 발음 - 두 단어 모두 자연스럽게 말할 수 있도록 발음 연습에 집중해야 합니다.

이러한 발음 연습은 영어 발음 교정에 큰 도움이 되며, 자신의 발음 수준을 높이는 데 기여합니다. 영상 내용을 통해 반복적으로 연습하면 말하기 능력을 한 단계 끌어올릴 수 있습니다.

이 영상의 문법

화자가 가장 많이 쓰는 문형을 영상 속 실제 표현과 함께 정리했습니다.

문형	영상 속 표현
수동태 be + 과거분사 — 누가 하는지보다 무슨 일이 일어나는지에 초점	are handled · is considered · is read
현재완료 have/has + 과거분사 — 과거의 일이 지금도 관련이 있을 때	that's been sent · have stored · has just used

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.

섀도잉 방법: 단계별 전체 가이드 읽기 →

쉐도잉 연습: 2.2k - 영상으로 영어 말하기 배우기

연습 모드 선택

앱 다운로드

추천 영상

System Design: How to Build an API Rate Limiter

02 English Vocabulary in Use Advanced Unit 5-8

What Is Redis Really About? Why Is It So Popular?

Cloud Models - CompTIA Network+ N10-009 - 1.3

JavaScript Visualized - Event Loop, Web APIs, (Micro)task Queue

What are Design Patterns? | Introduction to Design Patterns and Principles | Geekific

How Does a URL Shortener Work?

Distributed Transactions Explained: 2 Phase Commit vs Saga Pattern

SD91: Reliability vs Scalability

Why 95% of Android Developers Get Use Cases Wrong

MCP Just Got a Whole Lot Better

System Design Mock Interview: Design Facebook Messenger

왜 이 영상을 통해 말하기 연습을 해야 할까요?

맥락 속의 문법과 표현

일반적인 발음 함정

이 영상의 문법

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법