38"#PPL

Chapter 0, Motivation

ۙ೥ͷ3&45ͷਓؾ͸ɺΞʔΩςΫνϟͷར఺ͷଟ͘Λؚ·ͳ͍ɺ΄΅3&45GVMͳ"1*ͷڻ ҟతͳ੒௕Λ΋ͨΒ͠·ͨ͠ɻ͜ͷ࣮༻తͳΨΠυΛ࢖༻ͯ͠ɺ࣌ؒͱͱ΋ʹਐԽ͢Δ༗ ༻ͳ3&45"1*Λઃܭ͢ΔͨΊʹඞཁͳ͜ͱΛֶͼ·͢ɻ͜ͷຊͰ͸ɺ͞·͟·ͳυϝΠ ϯʹ·͕ͨΔιϦϡʔγϣϯʹয఺Λ౰ͯɺੈքͰ࠷΋੒ޭ͍ͯ͠Δ෼ࢄίϯϐϡʔςΟ ϯάγεςϜͰ͋Δ8PSME8JEF8FC༻ʹઃܭ͞ΕͨπʔϧΛ࢖༻ͯ͠ɺڧྗͰ҆શͳΞ ϓϦέʔγϣϯΛ࡞੒͢Δํ๏Λࣔ͠·͢ɻ

ίϨΫγϣϯύλʔϯ΍७ਮͳϋΠύʔϝσΟΞΛؚΉ"1*ઃܭઓུΛݕ౼͢Δ ϋΠύʔϝσΟΞ͕දݱΛҰ؏ͨ͠"1*ʹ݁ͼ෇͚Δํ๏Λཧղ͢Δ 9.%1͓Αͼ"-14ϓϩϑΝΠϧܗ͕ࣜͲͷΑ͏ʹ8FC"1*ͷʮηϚϯςΟοΫνϟϨϯ δʯΛຬͨ͢ͷʹ໾ཱ͔ͭΛൃݟ͢Δ μʔεʹ͍ۙඪ४Խ͞ΕͨϋΠύʔϝσΟΞσʔλܗࣜͷৄࡉ "1*࣮૷Ͱ)551Λ࢖༻͢ΔͨΊͷϕετϓϥΫςΟεΛద༻͢Δ +40/-%ඪ४͓ΑͼͦͷଞͷϦϯΫσʔλΞϓϩʔνΛ࢖༻ͯ͠8FC"1*Λ࡞੒͢Δ ૊ΈࠐΈγεςϜͰ3&45Λ࢖༻͢ΔͨΊͷ$P"1ϓϩτίϧΛཧղ͢Δ

No content

https://twitter.com/fielding/status/11081776593752

https://www.slideshare.net/ColdFusionConference/a-bit-of-rest/

No content

https://www.tbray.org/ongoing/When/201x/2018/11/18/Post-REST

• RESTful imperfections • Latency, Coupling, or Short life • A word on GraphQL, RPC • Post-REST: • Messaging and Eventing • Orchestration ] • Persistent connections • Brave New World! ·

A word on RPC · By which, these days, I guess I must mean gRPC. I dunno, I’m old enough that I saw generation after generation of RPC frameworks fail miserably; brittle, requiring lots of configuration, and failing to deliver the anticipated performance wins. Smells like making RESTful APIs more tightly coupled, to me, and it’s hard to see that as a win. But I could be wrong. ¶

Brave New World! · REST still provides a good clean way to decompose complicated problems, and its extreme simplicity and resilience will mean that if you want to design networked apps, you’re still going to have to learn that way of thinking about things.

No content

https://www.infoq.com/jp/articles/overcoming-restlessness/ "RESTlessness"Λࠀ෰͢Δ GraphQL΍gRPCɼApache Kafkaͱ͍ͬͨ৽͍͠APIϓϩτίϧ͕ɼRESTʹج͍ͮͨHTTP APIʹ ୅ΘΔ΋ͷͱͯ͠ਓؾΛूΊ͍ͯ·͢ɻ͜ͷهࣄͰ͸ɼRESTύϥμΠϜͷ௕ॴ͸1ର1ͷϓϩτί ϧൺֱͰ͸දݱͰ͖ͳ͍ɼͱ͍͏ओுΛల։͠·͢ɻRESTͷ୅ΘΓΛ୳͢ͷͰ͸ͳ͘ɼιϑτ ΢ΣΞΤϯδχΞ࢈ۀ͸ɼ੒ख़ͨ͠RESTΤίγεςϜΛج൫ͱͯ͠ɼ৽ͨͳϓϩτίϧͷٕज़త ௕ॴΛ୳ٻ͢ΔखஈΛ໛ࡧ͢Δ΂͖Ͱ͢ɻ

https://www.infoq.com/jp/articles/overcoming-restlessness/ RESTlessͷগͳ͍ະདྷ΁ ݌఻͞ΕΔςΫϊϩδτϨϯυ͸ଟ͘ͷ৔߹ɺݹ͍ΞϓϩʔνΛ৽ͨͳΞϓϩʔνͰஔ͖׵͑Δ͜ ͱΛᨳ͍·͢ɻ͔͠͠ݱ࣮ʹ͸ɺιϑτ΢ΣΞΤϯδχΞϦϯάͷਐԽ͸௨ৗɺ૚Λ੒ͯ͠ى͜Δ ΋ͷͰ͢ɻ৽ͨͳٕज़ֵ৽͕ɺͦΕʹଓ͘৽ͨͳΠϊϕʔγϣϯͷجૅΛங͘ͷͰ͢ɻGraphQL΍ gRPC΍KafkaͷΑ͏ͳ৽͍͠APIϓϩτίϧ͸ɺҰ෦ͷ෼ࢄॲཧͷγφϦΦʹ͓͍ͯ͸ɺϦιʔε Λج൫ͱͯ͠ɺJSONͰΤϯίʔυ͞ΕɺHTTPͰసૹ͞ΕΔϝοηʔδΛஔ͖׵͑ΔͰ͠ΐ͏ɻ ͨͩ͠ɺ෼ࢄγεςϜͷਐԽʹ͓͚ΔRESTͷҨ࢈͸ɺͦͷ࣮૷ͷৄࡉʹ͍ͭͯͰ͸ͳ͘ɺϢχ όʔαϧ઀ଓͷϑϨʔϜϫʔΫΛఏڙ΍ɺαʔϏείϯγϡʔϚʔΛϓϩόΠμʔ͔Β੾Γ཭͠ɺ ࢖͍΍͢͞ͱΞΫηγϏϦςΟΛڧௐ͢ΔϢϏΩλεʢภࡏʣͳಛੑʹΑΔ΋ͷͰ͢ɻ WebͷΞʔΩςΫνϟελΠϧͱͯ͠౰ॳఆٛ͞Ε͍ͯͨRESTΛɺϙετWebύϥμΠϜͷιϑ τ΢ΣΞΤϯδχΞϦϯάͷجૅͱ͢Δ͜ͱ͕Ͱ͖Δͷ͸ɺ͜ΕΒͷಛੑͰ͢ɻ

This chapter explains basic terminology using a RESTful system you’re already fa- miliar with: a website. Chapter 2, A Simple API This chapter translates the lessons of the Web to a programmable API with identical functionality to the website discussed in Chapter 1. xviii | Introduction Chapter 3, Resources and Representations Resources are the fundamental concept underlying HTTP, and representations are the fundamental concept underlying REST. This chapter explains how they’re re- lated. Chapter 4, Hypermedia Hypermedia is the missing ingredient that ties representations together into a co- herent API. This chapter shows what hypermedia is capable of, mostly using a hypermedia data format you’re already familiar with: HTML. The next four chapters describe different strategies for designing a hypermedia API: Chapter 5, Domain-Specific Designs The obvious strategy is to design a completely new standard that deals with your exact problem. I use the Maze+XML standard as an example. Chapter 6, The Collection Pattern One pattern in particular—the collection pattern—shows up over and over again in API design. In this chapter, I show off two different standards that capture this pattern: Collection+JSON and AtomPub. Chapter 7, Pure-Hypermedia Designs When the collection pattern doesn’t fit your requirements, you can convey any representation you want using a general-purpose hypermedia format. This chapter shows how it works using three general hypermedia formats (HTML, HAL, and Siren) as examples. This chapter also introduces HTML microformats and micro- data, which lead in to the next chapter. Chapter 8, Profiles A profile fills in the gaps between a data format (which can be used by many different APIs) and a specific API implementation. The profile format I recommend is ALPS, but I also cover XMDP and JSON-LD. In this chapter, my advice begins to outstrip the state of the art at the time this book was written. I had to develop the ALPS format for this book, because nothing else would do the job. If you’re already familiar with hypermedia-based designs, you might be able to skip up to Chapter 8, but I don’t think you should skip past it. Chapters 9 through 13 cover practical topics like choosing the right hypermedia format and getting the most out of the HTTP protocol. Chapter 9, The Design Procedure

Chapter 1, Surfing the Web

No content

Resources and Representations Whatever document the server sends, we call that document a representation of the resource. Addressability Every resource should have its own URL.

No content

Short Sessions "The server has already forgotten about her. ". = Stateless = (the server doesn’t care what state the client is in.) " Self-Descriptive Messages HTML document you receive doesn’t just give you the immediate information you asked for. The document also helps you answer the question of what to do next.

No content

No content

Standardized Methods I used GET for both “show the home page” and “show the message list,” State Application State and Resource State

"MJDF`TBEWFOUVSFUIFDMJFOU`TQFSTQFDUJWF

"MJDF`TBEWFOUVSFUIFTFSWFS`TQFSTQFDUJWF

Connectedness • "each web page tells you how to get to the adjoining pages. " • “hypermedia as the engine of application state,” "

The Web Is Something Special "If you compare the World Wide Web to its early competitors, you’ll see the difference. " Gopher, FTP, Archie, Veronica, Jughead, WAIS, and Prospero Once the Web took over, it became a lot more difficult to justify creating a new appli- cation protocol.