In order to start the draft of a policy for RESTFul services, participants of this OGC Standards Working Group embarked on the development of RIP, a RESTful service acaluator that assesses and report on RESTful services against a continuously updated set of user stories and acceptance criteria. Many patterns are starting to emerge but there is more work to do especially in testing upcoming Hypermedia API's. RIP is certainly a great learning tool and provides a good insight in the evolution of RESTful services. It may be pointing to a set of best practices that could be used at the enterprise level.
An entertaining tour of several wise epigrams and admonishments on REST, Hypermedia, and Web APIs delivered via celebrity Internet memes such as Inigo Montoya, Yoda, "The Most Interesting Man in the World", Boromir, Fry, and others. Although humorous, each character has something serious to tell us about the nature and challenges of services on the Web.
How do web service providers advertise their capabilities? By what alchemy do clients turn vague instructions from the server into specific HTTP requests? A talk about hypermedia and code on demand, as well as the not-so-great techniques web service designers (myself included) have been using instead of hypermedia and code on demand.
Imagine a SensorWeb with millions of service of various types that could be accessed by humans or automatically by machines over the web…sensor gauges in Namibia connected to forecasting models in the US and earth-orbiting satellites ready to image the upcoming flood on-demand. What architectural patterns may be required of these services to meet the challenge? Based on many observed best practices, which ones may need to be instituted for seamless interoperability over time? The Open Geospatial Consortium has defined a multitude of standardized services. Over the last 25 years, those standards have evolved from a REST/RPC style to SOAP and a newer binding style is now being considered. This presentation will focus on some of the contemplated best practices that could be used to define a policy for a REST/Hypermedia API to be used at this enterprise level.
We set out to build a HATEOAS server that had all the bells and whistles, only to find, well, not many pre-existing bells and whistles. By necessity we had to build our own HATEOAS server and figure out how to turn our complex e-commerce process into an API that required little training to succeed with. This talk will cover that journey and give some insight as to how to do it yourself.
