Downloaded 13 times
![Example: Bookstore "dg:affordances": [ { "@type": ["schema:Action","hydra:Operation"], "@id": "/RemoveBook", "hydra:method": "DELETE", "hydra:expects": "schema:Book", "hydra:title": "Deletes a Book resource.", "hydra:returns": "owl:Nothing", "rdfs:label": "Deletes the Book resource." },](https://image.slidesharecdn.com/ws-rest2015-150518094142-lva1-app6892/75/Adding-Rules-on-Existing-Hypermedia-APIs-14-2048.jpg)
![Tools Around Spec ● API Builder ● PyAPI o from [Swagger, API Blueprints, Hydra, WADL, RAML] to [Swagger, API Blueprints, Hydra, RAML] ● PyRIF o from [RuleML, RIF, SWRL] to [RuleML, RIF, SWRL] ● DeepGraphs Parser ( Soon ) ● DeepGraphs Reasoner ( Soon ) o Datalog Approach o FSM resolver implemented now o Fluent Editor has been used for Evaluation](https://image.slidesharecdn.com/ws-rest2015-150518094142-lva1-app6892/75/Adding-Rules-on-Existing-Hypermedia-APIs-22-2048.jpg)
Uploaded byMichael Petychakis
Adding Rules on Existing Hypermedia APIs
The document discusses the integration of rules into existing hypermedia APIs, emphasizing the need for a structured approach to manage API interactions through frameworks like DeepGraphs. It presents methodologies for modeling hypermedia responses and outlines future tool developments aimed at enhancing interoperability and reasoning over the web. The author, Michael Petychakis, highlights the project's advancements and invites community engagement for further collaborations.
Adding Rules on Existing Hypermedia APIs
- 1. Adding Rules on ExistingHypermedia APIs Michael Petychakis, Fenareti Lampathaki, Dimitrios Askounis National Technical University of Athens WS-REST, 18th May 2015, Florence Italy
- 2. Who I am MichaelPetychakis Researcher in DSS lab, National Technical University of Athens (NTUA) PhD Candidate in NTUA Electrical and Computer Engineer, Dipl.-M.Eng., NTUA Research Interests APIs/Linked Data/Web 3.0 @mpetyx
- 3. Web, APIs, IoTand .. Hypermedia
- 4. REST (as wassupposed to be) Level 3: Hypermedia Level 2: HTTP Verbs Level 1: Resources Level 0: POX
- 5. REST (today) Level 3: Hypermedia Level2: HTTP Verbs Level 1: Resources Level 0: POX
- 6. Hypermedia as FSM "hydra:member": [ { "@type": "schema:Basket", "schema:contains": [ { "@id": "/books/1", "@type": "schema:Book", "schema:author": "James Joyce", "schema:title": "Ulysses" },
- 7. Rules are Goodfor FSM If This then That If Basket_Contains( ?Book ) loggen_in_validated_user( ?Michael ) paypal_account_integrated( ?Michael ) Then Checkout( ?Michael, ?Book )
- 8. Rules on theWeb dc:description Rules SWRL Ruleml RIF Rule Inference Producing valid statements within rule based system
- 9. Rules are therefor a Loong Time Not Web Web
- 10. Blending Rules andAPIs Hydra/JSON_LD SWRL DeepGraphs
- 11. DeepGraphs Approach Goal: ModellingHypermedia Responses 1 Vocabulary Hydra Documents SWRL Rules JSON-LD Responses 1 Vocabulary
- 12. Vocabulary • Affordances • Duration(maxAllowedDuration) •According to latest updates on Http 1.1 • Parallel Processes • Synchronizing multiple FSM Clients • Constraints • The Actual Rules Schema:activity Hydra:Resource dg:affordances
- 13. Similar Approaches/ MediaTypes DeepGraphs Mason Uber JSON-LD JSON API Siren HAL Collection JSON JSON Schema JSON Hyper Schema XML Schema
- 14. Example: Bookstore "dg:affordances": [ { "@type":["schema:Action","hydra:Operation"], "@id": "/RemoveBook", "hydra:method": "DELETE", "hydra:expects": "schema:Book", "hydra:title": "Deletes a Book resource.", "hydra:returns": "owl:Nothing", "rdfs:label": "Deletes the Book resource." },
- 15.
- 16.
- 17. Complexity grows Exponentially Clients Bookstore Paypal Sms Agent Email Facebook Twitter Servers Bookstore Paypal Sms - Email Facebook Twitter CanWe Avoid Building one Client per Server and Vice Versa?
- 18. DeepGraphs Generic ServerImplementations • Developer Designs the FSM • A designer’s console for: Designing the API Atlas Verification of API FSM Validation (Running Example Workflows) Adding Integrity Constraints Defining the Business Logic through Rules
- 19.
- 20. DeepGraphs Generic AIClients SW Interoperabilty Reasoning REST Multiple Servers Multiple Transactions
- 21. In APIs WeTrust
- 22. Tools Around Spec ●API Builder ● PyAPI o from [Swagger, API Blueprints, Hydra, WADL, RAML] to [Swagger, API Blueprints, Hydra, RAML] ● PyRIF o from [RuleML, RIF, SWRL] to [RuleML, RIF, SWRL] ● DeepGraphs Parser ( Soon ) ● DeepGraphs Reasoner ( Soon ) o Datalog Approach o FSM resolver implemented now o Fluent Editor has been used for Evaluation
- 23. Dereferencable Rules onthe Web SWRL and Rif Solution: Declare 1 Rule within a Graph, and Reference this. Status: Working, But.. dg:constraint http://deepgraphs.org/repository/rule1
- 24. Advances of theMethodology • DeepGraphs is not only REST XMPP MQTT CoAP, DDS, AMQP (and more!) • DeepGraphs aims into reusing Existing APIs that speak Swagger, RAML, etc • DeepGraphs aims to facilitate: • Distributed Reasoning over the web with Affordances
- 25. Next Steps 1. FirstRelease of the Specification on June 2. Create a public Community Group 3. DeepGraphs Tools • Parser • Client • Reasoner • Designer 4. More Events 5. Address Rule Dereferencability by open discussion
- 26. Thank you Michael Petychakis <a href="mailto:mpetyx@epu.ntua.gr?Subject= Hello"target="_top">Drop me an e-mail</a> @mpetyx This work has been created in the context of the EU-funded project OPENi (Open-Source, Web-Based, Framework for Integrating Applications with Social Media Services and Personal Cloudlets), Contract No: FP7-ICT-317883.
Editor's Notes
- #4 http://theconnectivist-img.s3.amazonaws.com/wp-content/uploads/2014/05/Unknown.png http://blogs-images.forbes.com/gilpress/files/2014/08/iconsWithImages_page-5.jpg
- #5 Level 0: Swamp of POX Level 0 uses its implementing protocol (normally HTTP, but it doesn't have to be) like a transport protocol. That is, it tunnels requests and responses through its protocol without using the protocol to indicate application state. It will use only one entry point (URI) and one kind of method (in HTTP, this normally is the POST method). Examples of these are SOAP and XML-RPC. Level 1: Resources When your API can distinguish between different resources, it might be level 1. This level uses multiple URIs, where where every URI is the entrypoint to a specific resource. Instead of going through http://example.org/articles, you actually distinguish between http://example.org/article/1 and http://example.org/article/2. Still, this level uses only one single method like POST. Level 2: HTTP verbs To be honest, I don't like this level. This is because this level suggests that in order to be truly RESTful, your API MUST use HTTP verbs. It doesn't. REST is completely protocol agnostic, so if you want to use a different protocol, your API can still be RESTful. This level indicates that your API should use the protocol properties in order to deal with scalability and failures. Don't use a single POST method for all, but make use of GET when you are requesting resources, and use the DELETE method when you want to delete a resources. Also, use the response codes of your application protocol. Don't use 200 (OK) code when something went wrong for instance. By doing this for the HTTP application protocol, or any other application protocol you like to use, you have reached level 2. Level 3: Hypermedia controls Level 3, the highest level, uses HATEOAS to deal with discovering the possibilities of your API towards the clients. More information about HATEOAS can be found below. - See more at: http://restcookbook.com/Miscellaneous/richardsonmaturitymodel/#sthash.7wi9wqne.dpuf
- #6 API discoverability and documentation Reuse of state transition logic across clients Ease of client development More flexibility for servers to evolve
- #7 http://csunplugged.org/wp-content/uploads/2015/03/rowboat_0.png1286488551 http://oldblogimages.metawrap.com/DFAsmall.png
- #8 http://cdn.makeuseof.com/wp-content/uploads/2011/09/ifttt-icon.png?92a7a3
- #21 https://lh3.ggpht.com/K2afaPvqzzq-36aXKmdVgniDGKy3bDURiuYRGcltAcIYoL9oABqIvU5hwtP0wlyOYA=h900