REST Enabling Your Oracle Database

Editor's Notes

• #4: This is a Safe Harbor Front slide, one of two Safe Harbor Statement slides included in this template. One of the Safe Harbor slides must be used if your presentation covers material affected by Oracle’s Revenue Recognition Policy To learn more about this policy, e-mail: Revrec-americasiebc_us@oracle.com For internal communication, Safe Harbor Statements are not required. However, there is an applicable disclaimer (Exhibit E) that should be used, found in the Oracle Revenue Recognition Policy for Future Product Communications. Copy and paste this link into a web browser, to find out more information.   http://my.oracle.com/site/fin/gfo/GlobalProcesses/cnt452504.pdf For all external communications such as press release, roadmaps, PowerPoint presentations, Safe Harbor Statements are required. You can refer to the link mentioned above to find out additional information/disclaimers required depending on your audience.
• #5: Describe a RESTful Design Pattern, that defines how RESTful APIs are typically structured Explain how Hyperlinks facilitate loose coupling between clients and servers and enable each to evolve at their own pace Talk about the challenges of modelling tabular relational data as hierarchical nested Web resources Describe how concurrency is handled on the Web Explain the options for securing REST APIs, and give detail on the options, note this could be a talk in itself (which it was @ OOW15 - CON1748)
• #6: RESTful APIs typically follow a very uniform pattern, termed the Resource Collection Focus is on modelling resources, and manipulating resources using uniform operations. Little emphasis on modelling operations
• #7: There have been many many remote procedure call/distributed communication protocols. Many have been very deeply specified with thousands of pages of specifications, but in the end the industry moved away from these protocols to a much looser concept. So loose it cannot even deemed a protocol, rather REST is referred to as an architectural style. REST won not by being the most advanced, or the most capable, or the most efficient, but by being the easiest to get to grips with. Which is both a blessing and a curse. The world is full of less than optimal REST APIs. Because REST is so approachable folks quickly move to building and shipping APIs without considering some of the more thorny issues that every distributed application has to deal with How to manage concurrency, how to deal with lost updates, co-ordinate transactions How to deal with unavailability How to deal with massive scale Oracle REST Data Services is designed to deal with many of these issues, we’ve done the hard thinking and chosen approaches to deal with these issues so developers using ORDS don’t need to worry about them so much. I want to draw a comparison between REST and another foundational technology, UNIX. When I think of UNIX I picture big air conditioned rooms in data centres full of big iron servers. But that’s not the reality of UNIX today. It’s not just data centres and backend servers. The reality is UNIX is all around you, you wear it on your wrist, you carry it in your pocket, it powers the movies you watch when sat on an aeroplane, it controls the car you drive, it is literally everywhere. It is part of the fabric of our reality, but it’s not something out there in front of you. It’s a building block, something atop which much of the rest of the technology in our lives is built upon. I’m sure everyone in this room knows how to get around in UNIX, I’m sure that wasn’t always the case, there was a time when all I knew was MS-DOS and Windows. UNIX was a foreign land, and even seemed like something that was fading away under the march of Windows, but that time was so long ago and now I can’t picture a future where knowing and being comfortable using UNIX won’t be a valuable skill for at least another decade or two. I feel REST is following a similar trajectory. It is almost as old as the HTTP protocol itself, and it’s popularity and ubiquity has taken a considerable amount of time to build, but now that it’s value has been recognised, I don’t see it’s utility being displaced until the next paradigm shift in computing technology occurs. It has become one of the building blocks we take for granted. And thus everyone needs to know and understand REST and more importantly every piece of technology involved in distributed computing needs to be a good and competent REST citizen.
• #8: Enables database developer to control access to the database, instead of offering free for all access, provide controlled APIs that execute well designed and performant SQL/PLSQL Remove client developer from having to worry about sizing and managing database connection pools.
• #13: RESTful APIs typically follow a very uniform pattern, termed the Resource Collection Focus is on modelling resources, and manipulating resources using uniform operations. Little emphasis on modelling operations
• #14: The Collection URI is the entry point to the API, it’s function is to list all the items in the collection and provide an endpoint for creating new resources. It is typically a concrete URI, without any wildcarding/patterning. The Item URI is parameterized/wildcarded, it represents the naming pattern for all Item Resources in the Collection. It’s function is to provide the detail of a resource, along with the means to update and/or delete the resource.
• #18: RESTful APIs typically follow a very uniform pattern, termed the Resource Collection Focus is on modelling resources, and manipulating resources using uniform operations. Little emphasis on modelling operations
• #22: Perform a GET on the Collection URI to retrieve the resource In ORDS the response is a JSON document with two main elements: items: lists the items in the collection links: provides hyperlinks to help navigate the collection (next) and to identify the URI to use to POST new Items to the Collection
• #23: Perform a GET on the Collection URI to retrieve the resource In ORDS the response is a JSON document with two main elements: items: lists the items in the collection links: provides hyperlinks to help navigate the collection (next) and to identify the URI to use to POST new Items to the Collection
• #25: Perform a GET on the Collection URI to retrieve the resource In ORDS the response is a JSON document with two main elements: items: lists the items in the collection links: provides hyperlinks to help navigate the collection (next) and to identify the URI to use to POST new Items to the Collection
• #26: Perform a GET on the Collection URI to retrieve the resource In ORDS the response is a JSON document with two main elements: items: lists the items in the collection links: provides hyperlinks to help navigate the collection (next) and to identify the URI to use to POST new Items to the Collection
• #38: In the live demonstration we saw an application built with Oracle JET to communicate with a set of REST APIs defined entirely using ORDS. I wanted to talk a little more about this integration and how powerful it is.
• #39: I talked earlier about how the loosely defined REST paradigm won out over the many deeply and strongly specified technologies that went before it. Forever a complaint with those technologies was the difficulty of achieving robust interoperability both between applications and framework technologies, particularly across vendors. Oracle JET and ORDS are built by two completely different teams in Oracle. We have never co-ordinated with each other, we’ve hardly even communicated with each other. Yet you can plug our two products together with great ease. We both adhere to a common Oracle standard, but even that standard is nowhere near as tightly specified as something like a CORBA spec. It seems paradoxical, how come when we have loosely specified completely uncoordinated developement of two products that they can fit together so easily, especially when past efforts which attempted to dot every i and cross every t failed to deliver such interoperability? This is what demonstrates the true power of REST and the reason it is has triumphed over other approaches. It has well defined semantics for the basic behaviours that are broadly applicable across many different types of applications. It has barely enough specification rather than too much specification. It would seem that humans co-ordinate better when there is a bare minimum of rules rather than where there are too many regulations to run foul off.