REST는 Roy Fielding의 박사학위 논문에서 처음 언급된 용어로서
네트워크로 연결된 시스템을 서술하는 구조적 양식의 하나입니다.
REST는 REpresentational State Transfer를 의미하는 약어입니다.
* 빈약한 실력으로 번역했기 때문에 다소 어색한 표현이 있을 수 있습니다. *
How I Explained REST to My Wife
아내에게 REST 설명하기
Sunday, December 12, 2004, Ryan Tomayko
2004년 12월 12일 일요일, 라이언 토메코 씀
Wife: Who is “Roy Fielding”?
"로이 필딩"이 누구야?
Ryan: Some guy. He’s smart.
어떤 사람인데, 아주 똑똑해.
Wife: Oh? What did he do?
그래? 무슨 일을 했길래?
Ryan: He helped write the first web servers and
then did a ton of research explaining why the web works the way it does.
His name is on the specification for the protocol that is used to get pages
from servers to your browser.
아파치 웹 서버를 개발하는데 참여했고, 웹의 동작원리에 대해
연구도 수 없이 했어. 웹 브라우져를 이용해서 웹 서버에 있는 문서를
읽어올 때 사용되는 통신규약이 있는데,
그 통신규약 정의서에 그의 이름이 있지.
* 본명은 Roy Thomas Fielding, 1965년 출생, 미국의 컴퓨터 과학자죠.
HTTP 정의서 - RFC 2616 : 1999년 6월 - 를 쓴 중요 저자 중 한 사람이며
컴퓨터 네트워크 분야의 권위자로 자주 인용되는 분입니다.
Wife: How does it work?
그건 어떻게 동작하는데?
Ryan: The web?
웹이 어떻게 동작하냐구?
Wife: Yeah.
응
Ryan: Hmm. Well, it’s all pretty amazing really.
And the funny thing is that it’s all very undervalued.
The protocol I was talking about, HTTP, it’s capable of
all sorts of neat stuff that people ignore for some reason.
음.. 그래, 웹은 정말 놀라울 정도야.
그리고, 웃긴 건 웹이 너무 과소평가 받는다는 거야.
내가 앞에서 말했던 통신규약은 'HTTP' 라는 것인데,
사람들이 가볍게 여길 정도로 간결하게 작동하고 있지.
Wife: You mean “http” like the beginning of what I type into the browser?
지금 말한 'http'는 내가 웹 브라우져 주소창에
맨 처음 입력하는 그 'http'와 같은 거야?
Ryan: Yeah. That first part tells the browser what protocol to use.
That stuff you type in there is one of the most important breakthroughs
in the history of computing.
그래. 그 부분은 웹 브라우져에게 사용할 통신규약이 무엇인지
알려주는 역할을 해. 당신이 입력한 그 부분은 컴퓨터 역사상
아주 중요한 발전들 중 하나야.
Wife: Why?
어째서야?
Ryan: Because it is capable of describing the location of something anywhere
in the world from anywhere in the world. It’s the foundation of the web.
You can think of it like GPS coordinates for knowledge and information.
세계 어디서든지, 세계 어느 곳에 있는 어떤 것의
위치를 나타낼 수 있기 때문이지. 이것이 웹의 기초야.
마치 정보와 지식을 GPS 좌표로 표시하는 것과 비슷한 거지.
Wife: For web pages?
웹 페이지를 위해서 만든 거구나?
Ryan: For anything really. That guy, Roy Fielding, he talks a lot about
what those things point to in that research I was talking about.
The web is built on an architectural style called “REST”.
REST provides a definition of a “resource”, which is what those things point to.
실제는 전부를 위한거지. '로이 필딩' 이라는 사람이 연구했던 것 중 하나가
'그것들을 지정하는 방법'에 대한 것이었어.
웹은 'REST'라는 구조적 양식을 바탕으로 구축되었지.
'REST'는 자원들의 정의를 제공하는데, '자원'이라는 것은
'지정해야 할 그것'을 말해.
Wife: A web page is a resource?
웹 페이지가 '자원'이야?
Ryan: Kind of. A web page is a “representation” of a resource.
Resources are just concepts. URLs—those things that you type into the browser…
자원의 한 종류야. 웹 페이지는 '자원'의 "대리표현"이지.
자원들은 그냥 개념적으로 생각해. 당신이 웹 브라우져에 입력하는 URL은..
* '자원'의 "대리표현"a representation of a resource 이라는 구문에
아주 중요한 개념이 있습니다. 예를 들어, 우리의 이름은
주민번호의 대리표현이라 할 수 있죠.
우리가 누군가를 부를 때, '철수야', '영희야'라고 하지,
'123456-1234567야'이나 '234567-2345678야' 처럼 주민번호로 부르지 않죠.
또, '철수에게 연락해'라고 하지, '123-4567-8901에게 연락해' 라고 하지는 않죠
Wife: I know what a URL is..
URL이 무엇인지는 나도 알아..
Ryan: Oh, right. Those tell the browser that there’s a concept somewhere.
A browser can then go ask for a specific representation of the concept.
Specifically, the browser asks for the web page representation of the concept.
아, 좋아. URL은 웹 브라우져에게 개념적으로 그것이 어딘가에 있다는 걸 말해.
그러면, 웹 브라우져는 개념적으로 존재하는 그것의 구체적인 대리표현을
요청해야겠지. 다시 말해, 웹 브라우져는 그것의 대리표현으로
웹 페이지를 요청해.
* 우리가 URL을 입력하면, 웹 브라우져는 DNS 서버를 이용해서
URL에 포함된 도메인명에 대한 IP 주소를 조회합니다. 웹 브라우져는
이 IP 주소를 이용해서 웹 서버에 접속하죠.
그런 다음, 서버에 저장된 데이터들의 대리표현 - 즉, html형태로 작성된
웹 페이지를 불러오면, 그것이 웹 브라우져에 보여지는 것이죠.
Wife: What other kinds of representations are there?
다른 대리표현들도 있어?
Ryan: Actually, representations is one of these things that doesn’t get used a lot.
In most cases, a resource has only a single representation.
But we’re hoping that representations will be used more in the future
because there’s a bunch of new formats popping up all over the place.
사실, 그렇게 다양하게 사용되지는 않아.
대부분의 경우, 자원은 한 가지 대리표현만 사용해.
하지만, 여기저기서 다양하고 새로운 형식이 계속 나타나기 때문에,
머지 않은 미래에는 다양한 대리표현이 많이 사용될 꺼야.
* 지금도 계속 다양한 장치들이 새롭게 나오고 있고,
이것들을 네트워크로 묶어서 장치에 들어있는 정보들을 주고 받으려면,
그것들을 위한 대리표현도 마찬가지로 많이 필요해지겠죠
Wife: Like what?
예를 들면?
Ryan: Hmm. Well, there’s this concept that people are calling “Web Services”.
It means a lot of different things to a lot of different people
but the basic concept is that machines could use the web just like people do.
음.. 사람들이 "웹 서비스"라고 부르는 개념이 그래.
사실 여러 사람들에게 여러가지 의미로 해석되고 있지만,
기본 개념은 사람들이 하는 것과 똑같이 기계도 웹을 사용한다는 거야.
* 웹 서비스는 서비스 지향적 분산 컴퓨팅 기술의 한 종류입니다.
즉, 멀리 떨어져 있는 컴퓨터 상의 프로그램이 다른 컴퓨터 안에 있는
프로시져나 함수, 메서드를 호출, 실행해서 원하는 결과를 얻도록
고안된 기술입니다.
웹 서비스의 프로토콜 구성은 SOAP, WSDL, UDDI 등으로 이루어져 있고,
모든 메시징 처리에는 XML이 사용되기 때문에 상호 운용성이 높습니다.
원격 호출remote method invocation을 하는 절차는 다음과 같습니다.
1) 호출할 함수나 메서드가 있는 서버를 알아낸다. (UDDI)
2) 원격 함수를 기술하는 언어로 코드를 작성하고 (WSDL)
3) 원격 함수나 메서드에 인자를 전달하고, 호출, 실행, 결과전달 받습니다. (SOAP)
W3C에서는 WS-*, BPEL4W등의 2세대 프로토콜을 준비 중 입니다.
웹 서비스 이전의 분산 컴퓨팅 기술들은 RPC, CORBA, DCOM, RMI등이 있습니다.
Wife: Is this another robot thing?
로봇들이 하는 그런 것 말야?
Ryan: No, not really. I don’t mean that machines will be sitting down at the desk and browsing the web.
But computers can use those same protocols to send messages back
and forth to each other. We've been doing that for a long time but none of the techniques
we use today work well when you need to be able to talk to all of the machines in the
entire world.
아냐, 기계가 책상 앞에 앉아 웹을 탐색한다는 의미가 아니라,
컴퓨터들이 동일한 통신규약을 이용해서 서로 정보교환을 한다는 말이야..
우리는 이런 것을 꽤 오랫동안 해 왔었지만,
오늘날 전 세계 모든 기계들이 메세지를 주고 받으며,
일을 해야 할 필요가 있을 때에는 정작 쓸만한 기술이 없었지.
Wife: Why not?
왜 없었어?
Ryan: Because they weren’t designed to be used like that.
When Fielding and his buddies started building the web,
being able to talk to any machine anywhere in the world was a primary concern.
Most of the techniques we use at work to get computers to talk to each other
didn’t have those requirements.
You just needed to talk to a small group of machines.
왜냐하면, 이런 것까지 할 꺼라 생각하지 못 한 거지.
'로이 필딩'과 그의 친구들이 '웹'을 만들기 시작했을 때에는,
세계 어느 곳에 있는 기계와도 정보를 교환할 수 있도록 만드는 것이
주된 관심사였어. 우리가 업무를 위해 정보교환할 때 사용하는
대부분의 기술은 이런 요구를 만족하지 못했어.
당신도 그냥 소규모 네트워크을 이용해서 정보를 교환하잖아.
Wife: And now you need to talk to all the machines?
모든 기계들과 정보교환을 해야 할 필요가 있어?
Ryan: Yes – and more. We need to be able to talk to all machines about all the stuff
that’s on all the other machines. So we need some way of having one machine tell
another machine about a resource that might be on yet another machine.
그럼. 그리고, 앞으로도 이럴 필요가 많아 질 꺼야.
우리는 어떤 기계에 있는 모든 내용에 대해
다른 기계들과 서로 얘기해야 할 필요가 있을 꺼야.
다시 말해, 우리는 '가'라는 기계가 '나'라는 기계에게,
'다'라는 기계에 있을지도 모르는 자원에 대해
말할 수 있는 방법이 필요하단 말이지.
Wife: What?
이해가 안돼.
Ryan: Let’s say you’re talking to your sister and
she wants to borrow the sweeper or something.
But you don’t have it – your Mom has it.
So you tell your sister to get it from your Mom instead.
This happens all the time in real life and it happens all the time when machines start talking too.
당신은 동생과 얘기하고 있는데, 그녀가 청소기 같은 것을 빌리고
싶어한다고 해. 당신에게는 없지만, 당신 엄마는 그것을 가지고 있어.
그럼, 당신은 나 대신 엄마한테서 빌리라고 동생에게 얘기해야 겠지.
이런 상황은 실제 생활에서 종종 일어나지만,
기계들 사이에서도 종종 일어날 수 있어.
* 웹으로 제공하고 있는 정보나 서비스를 융합하여
새로운 소프트웨어나 서비스, 데이터베이스등을 만드는 것을
매시업Mashup이라고 부릅니다.
자사의 기술을 웹 서비스로 구축하고, API를 공개하면
이들 기능에 독자적인 인터페이스를 조합해서 새로운 서비스를
제공할 수 있게 되죠.
외국에는 구글, 아마존, 국내는 다음, 네이버가
Open API형태로 자사 주요 서비스를 제공하고 있습니다.
Wife: So how do the machines tell each other where things are?
그럼, 기계는 그것이 어디에 있는지 어떻게 얘기해?
Ryan: The URL, of course. If everything that machines need to talk
about has a corresponding URL, you've created the machine equivalent of a noun.
That you and I and the rest of the world have agreed on talking about
nouns in a certain way is pretty important, eh?
물론 URL이지.
만일, URL을 통해 기계에 있는 모든 정보들을 교류하려면,
그것을 의미하는 '명사'가 있어야 해.
당신과 나, 그리고 이 세계의 모든 사람들은
그런 명사로 말하는 것을 중요하게 여겨, 맞지?
* 볼펜, A4용지, 보드마커, 가위, 스템플러 등 : 사무용품
국자, 냄비, 후라이팬, 밥솥, 가스렌지 등 : 주방기기
Wife: Yeah.
응.
Ryan: Machines don’t have a universal noun – that’s why they suck.
Every programming language, database, or other kind of system
has a different way of talking about nouns. That’s why the URL is so important.
It let’s all of these systems tell each other about each other’s nouns.
기계들에게는 보편적인 명사가 없어 - 이래서 기계가 맘에 안 들어.
모든 프로그래밍 언어, 데이터베이스, 그 외 여러 시스템들이
명사를 얘기할 때는 각자의 방식으로 하고 있어.
URL이 중요한 이유가 바로 이것 때문이지.
이 덕택에 모든 시스템들은 각자의 명사들을 서로에게 얘기할 수 있어.
* 예를 들어, 자바나 C#의 경우 '클래스'로, 데이터 베이스에서는
'테이블'로 명사를 나타내고 있습니다.
성적 클래스 나 성적 테이블의 내용을 웹 페이지를 통해
나타 낼려면 어떻게 할까요? 간단하게 http://~~~/~~~/SungJuk.do 나
http://***/***/SungJuk.jsp라 하면 되지 않을까요?
Wife: But when I'm looking at a web page, I don’t think of it like that.
하지만, 내가 웹 페이지를 볼 때는, 그런 건 생각 안 하는 걸.
Ryan: Nobody does. Except Fielding and handful of other people.
That’s why machines still suck.
아무도 그러지 않지. 단, '로이 필딩'과 소수의 몇몇 사람들만 생각해.
정말 기계가 맘에 안 들어.
Wife: What about verbs and pronouns and adjectives?
그럼, 동사, 대명사, 형용사 같은 것도 있어?
Ryan: Funny you asked because that’s another big aspect of REST.
Well, verbs are anyway.
질문이 다소 웃기지만, 이것도 REST의
또 다른 중요한 관점이지. 암튼, 동사만 있어.
Wife: I was just joking.
그냥 농담이었는데.
Ryan: It was a funny joke but it’s actually not a joke at all.
Verbs are important. There’s a powerful concept
in programming and CS theory called “polymorphism”.
That’s a geeky way of saying that different nouns can have the same verb applied to them.
재미있는 농담이었지만, 전혀 농담처럼 여겨지지 않아.
동사들은 아주 중요해. 프로그래밍과 컴퓨터 과학 이론에는
'다형성'이라는 막강한 개념이 존재해. 즉, 서로 다른 명사들에
같은 동사를 적용할 수 있는 특이한 방식이지.
* 다형성은 객체 지향 프로그래밍에서 아주 중요한 개념들 중 하나죠.
Wife: I don’t get it.
무슨 말인지 모르겠어.
Ryan: Well.. Look at the coffee table. What are the nouns?
Cup, tray, newspaper, remote.
Now, what are some things you can do to all of these things?
음.. 커피 테이블을 상상해 봐. 여기에 명사는 뭘까?
컵, 쟁반, 신문, 리모콘 등이 있겠지.
그럼, 이것들로 뭘 할 수 있을까?
Wife: I don’t get it…
모르겠어..
Ryan: You can get them, right? You can pick them up.
You can knock them over. You can burn them.
You can apply those same exact verbs to any of the objects sitting there.
왜 몰라? 그걸 들어올리거나, 그걸 탁탁 치거나, 그걸 태울 수도 있어.
여기 있는 어떤 물체에 동일한 동사를 적용할 수도 있어.
Wife: Okay… so?
좋아.. 그래서?
Ryan: Well, that’s important. What if instead of me being able to say to you,
“get the cup,” and “get the newspaper,” and “get the remote”;
what if instead we needed to come up with different verbs for each of the nouns?
I couldn’t use the word “get” universally,
but instead had to think up a new word for each verb/noun combination.
동일한 동사를 적용한다는 게 중요한 거야.
내가 당신에게 나 대신 '컵 좀 줘', '신문 좀 줘', '리모콘 좀 줘'라고 말했다 쳐;
만일 명사들마다 다른 동사를 적용해야 한다면 어떨까?
보편적으로 사용하는 단어인 '줘'를 사용하지 않으면,
동사/명사 조합에 맞춰 새로운 단어를 생각해야겠지.
Wife: Wow! That’s weird.
와우! 정말 신기하다.
* 그걸 들어, 그걸 쳐, 그걸 태워 : 명사에 다른 동사를 적용
'컵 줘', '신문 줘', '리모콘 줘' : 명사에 같은 동사를 적용
Ryan: Yes, it is. Our brains are somehow smart enough to know that the same verbs
can be applied to many different nouns. Some verbs are more specific
than others and apply only to a small set of nouns.
For instance, I can’t drive a cup and I can’t drink a car.
But some verbs are almost universal like GET, PUT, and DELETE.
그래, 그렇지. 우리의 뇌는 워낙 똑똑해서, 수 많은 명사에 대해
동일한 동사를 적용할 수 있어. 어떤 동사는 좀 특별해서
특정 명사들에만 적용해야 하는 경우가 있지만 말야.
예를 들어, '난 컵을 운전할 수 없어'와 '난 차를 운전할 수 없어'등이지.
하지만, 어떤 동사들은 GET, PUT, DELETE 처럼 대부분 보편적이야.
Wife: You can’t DELETE a cup.
당신은 컵을 'DELETE' 할 수 없어.
Ryan: Well, okay, but you can throw it away. That was another joke, right?
음, 좋아. 당신은 그것을 ‘THROW’할 순 있겠지.
이것도 농담이지, 그렇지?
Wife: Yeah.
응.
Ryan: So anyway, HTTP—this protocol Fielding and his friends created—is
all about applying verbs to nouns. For instance, when you go to a web page,
the browser does an HTTP GET on the URL you type in and back comes a web page.
암튼, HTTP - '필딩'과 그의 친구들이 창조한 - 는 모든 명사에 동사를 적용하는 일을 하지.
예를 들어, 어떤 웹 페이지를 볼려면, 웹 브라우져는 당신이 입력한 URL에
HTTP GET 동사를 붙여 실행하고, 그 결과로 웹 페이지를 가지고 오지.
Web pages usually have images, right? Those are separate resources.
The web page just specifies the URLs to the images and the browser goes and
does more HTTP GETs on them until all the resources are obtained and
the web page is displayed. But the important thing here is that
very different kinds of nouns can be treated the same.
Whether the noun is an image, text, video, an mp3, a slideshow, whatever.
I can GET all of those things the same way given a URL.
웹 페이지에는 종종 그림이 포함될 수도 있어, 그렇지? 이건 별도의 자원이야.
웹 페이지는 단지 이미지의 URL만 가리키고 있어. 웹 브라우져가 동작해서
모든 자원을 획득할 때까지 여러 번의 HTTP GET을 실행하고 나면
비로소 웹 페이지가 표시돼. 하지만, 여기서 중요한 것은
수 많은 다른 명사라 할지라도 결국 동일한 것으로 취급된다는 거야.
다시 말해, 명사가 이미지, 문서, 동영상, 오디오, 슬라이드등 이라도 말야.
그것이 URL로 주어지기만 하면, GET으로 무엇이든 다 가져올 수 있어.
* 한가지 예로 웹 브라우져를 하나 실행하고
여러분이 자주 가는 사이트(예, 한계레)로 이동한 다음,
적당한 게시물이나 기사를 선택하시고,
[파일] - [다른 이름으로 저장]이라는 메뉴를 선택합니다.
파일 저장 형식은 mht로 지정하고, 적당한 이름을 입력한 다음,
[확인]을 누르면, 대화상자에 빠르게 표시되는 수많은
URL이 보일 겁니다. 겉으로는 URL로 단순하게 나타내지만,
내부적으로는 다양하고 복잡한 절차를 거친다는 걸 유의하세요.
Wife: Sounds like GET is a pretty important verb.
GET은 아주 중요한 동사처럼 들리네.
Ryan: It is. Especially when you’re using a web browser
because browsers pretty much just GET stuff.
They don’t do a lot of other types of interaction with resources.
This is a problem because it has led many people to assume that HTTP is just for GETing.
But HTTP is actually a general purpose protocol for applying verbs to nouns.
당연해. 당신이 웹 브라우져를 사용할 때, 특별히 많이 사용하는 동사가 GET이야.
그 외 다른 종류의 상호작용은 없어. 이 덕택에 많은 사람들이
'HTTP는 늘 GET만 해'라고 오해하게 만든다는 게 문제야.
어쨋든, HTTP는 명사에 동사를 적용하는 일반적인 통신규약이야.
* HTTP 프로토콜은 마치 맥가이버 칼과 비슷하죠. 모양은 작지만
짜르기, 쪼기, 찝기, 벗기기, 따기, 뽑기 등이 다 돼죠.
Wife: Cool. But I still don’t see how this changes anything.
What kinds of nouns and verbs do you want?
멋지긴 한데, 난 아직도 모르겠어.
또 설명해 줄 명사와 동사가 있어?
Ryan: Well the nouns are there but not in the right format.
Think about when you’re browsing around amazon.com looking for
things to buy me for Christmas.
Imagine each of the products as being nouns. Now, if they were available in a
representation that a machine could understand, you could do a lot of neat things.
음, 명사가 있지. 근데, 일반적인 것과는 좀 달라.
당신은 나에게 성탄절에 사줄 선물을 고르기 위해
아마존 닷컴을 둘러보는 중이라 생각해 봐. 각각의 상품들을 명사라고 상상해 봐.
만일, 그것들이 기계가 이해할 수 있는 대리표현들로 되어 있다면,
기계가 당신을 대신해서 많은 것을 해주었을꺼야.
Wife: Why can’t a machine understand a normal web page?
왜 기계는 일반적인 웹 페이지를 이해 못해?
Ryan: Because web pages are designed to be understood by people.
A machine doesn’t care about layout and styling.
Machines basically just need the data.
Ideally, every URL would have a human readable and
a machine readable representation.
When a machine GETs the resource, it will ask for the machine readable one.
When a browser GETs a resource for a human, it will ask for the human readable one.
웹 페이지는 사람에 의해 이해되게 끔 만들어 졌거든.
반면, 기계는 웹 페이지의 외형이나 양식은 신경 쓰지 않아.
기계들은 기본적으로 데이터에만 신경 쓰지.
가장 좋은 건, 모든 URL은 인간이 읽기 쉬워야 함과 동시에
기계들도 그에 대한 대리표현을 읽을 수 있도록 하는거야.
기계가 자원을 GET하려 할 때, 그것은 기계가 읽을 수 있는 대리표현이어야 해.
반면, 웹 브라우져가 자원을 GET 하려 할 때, 그것은 인간이 읽을 수 있는 표현이어야겠지.
* HTML보다 XHTML을 사용하려는 이유가 바로 저것이죠
Wife: So people would have to make machine formats for all their pages?
그럼, 모든 페이지들을 기계들이 이해할 수 있는 형식으로 만들어야 해?
Ryan: If it were valuable.
Look, we've been talking about this with a lot of abstraction.
How about we take a real example.
필요하다면 그렇게 해야겠지.
지금까지는 추상적으로만 얘기해 왔으니
실제 예를 한번 들어 볼께.
You’re a teacher – at school I bet you have a big computer system,
or three or four computer systems more likely, that let you manage students:
what classes they’re in, what grades they’re getting, emergency contacts,
information about the books you teach out of, etc.
당신은 선생님이야 - 학교에서 당신은 대략 3 - 4대 정도의
컴퓨터 시스템을 가지고 있는데, 학생들을 관리하는데 그걸 쓰고 있어.
여기에는 강의를 듣는 학생들 정보, 학생들 성적, 비상 연락망, 당신이
강의하는 과목의 정보 등이 담겨 있다고 해.
If the systems are web-based, then there’s probably a URL
for each of the nouns involved here:
student, teacher, class, book, room, etc.
만일, 시스템이 웹 기반이라면, URL에는 다음과 같은 명사들이 포함되겠지 :
학생, 교사, 학급, 교과서, 강의실 등등.
Right now, getting the URL through the browser gives you a web page.
If there were a machine readable representation for each URL,
then it would be trivial to latch new tools onto the system
because all of that information would be consumable in a standard way.
지금은 웹 브라우져로 웹 페이지를 보기 위해 URL을 입력하고 있어.
입력한 URL 에 대해 기계가 읽을 수 있는 대리표현이 존재한다면,
새로운 도구로 시스템에 빗장을 걸면 쉽게 끝날꺼야.
이렇게 하면 일반적인 방식으로 모든 정보를 처리할 수 있어.
* URL에 xml, json, xhmtl 등이 일부 포함되겠죠.
It would also make it quite a bit easier for each of the systems to talk to each other.
Or, you could build a state or country-wide system that was able to talk to each of
the individual school systems to collect testing scores.
The possibilities are endless.
이렇게 되면 각 시스템들끼리 정보교환도 매우 쉬워져.
각 학교의 성적 자료를 수집하기 위한
주 또는 지역 단위 시스템도 구축할 수 있어.
가능성은 무궁무진하지.
Each of the systems would get information from each other using a simple HTTP GET.
If one system needs to add something to another system, it would use an HTTP POST.
If a system wants to update something in another system, it uses an HTTP PUT.
The only thing left to figure out is what the data should look like.
각각의 시스템들은 간단하게 HTTP GET으로 서로에게서 정보를 얻어올 수 있어.
‘가’ 시스템이 ‘나’ 시스템에 ‘다’를 추가하려면, HTTP POST를 이용하면 돼.
‘가’ 시스템이 ‘나’ 시스템의 ‘다’를 변경하려면, HTTP PUT를 이용하면 돼고.
이 ‘다’를 어떻게 보여줄 것 인지만 생각하면 돼.
* REST의 가장 핵심적이고 중요한 개념을 설명하는 단락입니다.
SOAP 프로토콜 없이, HTTP 프로토콜만으로 처리한다는 것이 중요합니다.
즉, URL에 질의문을 붙여 쓰지 않고 단지, POST, GET, PUT, DELETE 등의
HTTP 고유/확장 명령을 이용하여 고정된 URL에 접근한다는 것 입니다.
나중에 스트러츠 2.1.x 의 REST 플러그 인을 이용해서 간단한 예제를
만들어 보기로 하고, 여기서는 개념적으로나마 살펴보도록 하죠.
예를 들어, 번호,이름,국어,영어,수학점수로 구성된 성적처리 프로그램을
REST 방식으로 만든다고 상상해 봅니다.
성적 데이터를 저장하기 위한 SungJuk클래스,
GET, POST, PUT, DELETE 명령에 대한 호출을 처리하기 위한
SungJukController 클래스, GET, POST, PUT, DELETE 명령에 대한 실제 처리 내용
(index(), create(), update(), destory())을 담고 있는 SungJukService 클래스등을 작성
해 둡니다. 그 다음에는 REST 실행을 위한 환경 설정을 해야겠죠.
전체 성적을 출력하려면, http://~~:8080/***/sungjuk 을 GET으로 호출합니다.
sungjuk은 SungJuk클래스의 이름을 그대로 참조했죠.
실행 결과는 xml, json, xhml형태로 나타납니다.
3번째 학생 성적을 출력하려면, http://~~:8080/***/sungjuk/3 을 GET으로
호출합니다.
새로운 성적을 입력하려면, 성적 데이터를 xml형태로 작성한 다음,
http://~~:8080/***/sungjuk 을 POST로 호출합니다.
3번째 학생 성적 데이터를 수정하려면, http://~~:8080/***/sungjuk/3 을
PUT으로 호출합니다.
3번째 학생 성적 데이터를 삭제하려면, http://~~:8080/***/sungjuk/3 을
DELETE로 호출합니다.
SungJukService 클래스에 show(), edit(), editNew() 메서드를 정의하면,
POST, PUT 명령을 사용하지 않고, 단지 GET 명령만으로 입력, 수정작업을
할 수 있습니다.
http://~~:8080/***/list.jsp, http://~~:8080/***/view.jsp?id=3,
http://~~:8080/***/update.jsp?id=3, http://~~:8080/***/delete.jsp?id=3
보다는 간결하고 깔끔해 보이죠?
Wife: So this is what you and all the computer people are working on now?
Deciding what the data should look like?
그럼, 당신과 컴퓨터 관련 일을 하는 사람들이 주로 이런 일을 해?
데이터를 어떻게 보여줄 건지 결정하는 거 말야?
* 웹 서비스나 REST는 메세징 교환시 주로 XML을 이용합니다.
블로그의 스킨 기능처럼 XHTML에 CSS를 적용하면
다양하게 표현할 수 있는 것처럼, XML에도 CSS나 XSL을 적용하면
다양한 형태로 결과를 나타낼 수 있습니다.
WEB 2.0과 시맨텍 웹의 중요한 개념인 '자료와 표현의 분리'에도 부합되는 것이죠.
Ryan: Sadly, no. Instead, the large majority are busy writing layers of complex specifications
for doing this stuff in a different way that isn’t nearly as useful or eloquent.
Nouns aren’t universal and verbs aren’t polymorphic.
그건 아냐. 대부분의 경우, 유용하지 않거나 설득력이 없는 방식으로
이걸 처리한답시구, 쓸데없이 복잡한 정의서를 작성하는 데 많은 시간을
쓰고 있어. 게다가 명사는 보편적이지 않고, 동사는 다형적이지도 않아.
We’re throwing out decades of real field usage and proven technique
and starting over with something that looks a lot like other systems that
have failed in the past. We’re using HTTP but only because it helps us talk to
our network and security people less.
We’re trading simplicity for flashy tools and wizards.
우리는 오랜 기간 동안 사용해 오면서 검증된 기술을 버리고,
과거에 실패했던 시스템과 많이 닮아 있는 어떤 것과 시작하려 하고 있어.
HTTP는 보안 담당자 없이 우리가 네트워크를 통해 정보교환하도록
도와줬기 때문에 여전히 이걸 쓰고 있지.
우린 지금 번쩍거리는 도구와 마법사를 위해 단순함을 맞바꾸려 하고 있어.
Wife: Why?
왜 그럴까?
Ryan: I have no idea.
나도 모르겠어.
Wife: Why don’t you say something?
당신이 그것에 대해 한마디 하면 어때?
Ryan: Maybe I will.
그래볼께.
출처 : http://tomayko.com/writings/rest-to-my-wife
