O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Adding Rules on Existing Hypermedia APIs

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 26 Anúncio

Adding Rules on Existing Hypermedia APIs

Baixar para ler offline

During the past years, the data deluge that prevails in the World
Wide Web has been accompanied by a number of APIs that
expose business logic. In this paper, we discuss a novel approach
to enrich existing API standards definitions with business rules.
Taking advantage of the REST principles, we aim at enabling the
creation of generic clients that can dynamically navigate through
semantically enriched web affordances with the help of Hydrabased
Hypermedia API descriptions, which encapsulate the finite
state machine of possible actions into SWRL rules.

During the past years, the data deluge that prevails in the World
Wide Web has been accompanied by a number of APIs that
expose business logic. In this paper, we discuss a novel approach
to enrich existing API standards definitions with business rules.
Taking advantage of the REST principles, we aim at enabling the
creation of generic clients that can dynamically navigate through
semantically enriched web affordances with the help of Hydrabased
Hypermedia API descriptions, which encapsulate the finite
state machine of possible actions into SWRL rules.

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Adding Rules on Existing Hypermedia APIs (20)

Anúncio

Mais recentes (20)

Anúncio

Adding Rules on Existing Hypermedia APIs

  1. 1. Adding Rules on Existing Hypermedia APIs Michael Petychakis, Fenareti Lampathaki, Dimitrios Askounis National Technical University of Athens WS-REST, 18th May 2015, Florence Italy
  2. 2. Who I am Michael Petychakis 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. 3. Web, APIs, IoT and .. Hypermedia
  4. 4. REST (as was supposed to be) Level 3: Hypermedia Level 2: HTTP Verbs Level 1: Resources Level 0: POX
  5. 5. REST (today) Level 3: Hypermedia Level 2: HTTP Verbs Level 1: Resources Level 0: POX
  6. 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. 7. Rules are Good for FSM If This then That If Basket_Contains( ?Book ) loggen_in_validated_user( ?Michael ) paypal_account_integrated( ?Michael ) Then Checkout( ?Michael, ?Book )
  8. 8. Rules on the Web dc:description Rules SWRL Ruleml RIF Rule Inference Producing valid statements within rule based system
  9. 9. Rules are there for a Loong Time Not Web Web
  10. 10. Blending Rules and APIs Hydra/JSON_LD SWRL DeepGraphs
  11. 11. DeepGraphs Approach Goal: Modelling Hypermedia Responses 1 Vocabulary  Hydra Documents  SWRL Rules  JSON-LD Responses 1 Vocabulary
  12. 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. 13. Similar Approaches/ Media Types DeepGraphs Mason Uber JSON-LD JSON API Siren HAL Collection JSON JSON Schema JSON Hyper Schema XML Schema
  14. 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. 15. Example in Diagrams
  16. 16. Complexity grows Exponentially Clients Bookstore Paypal Sms Agent Email Facebook Twitter Servers Bookstore Paypal Sms - Email Facebook Twitter
  17. 17. Complexity grows Exponentially Clients Bookstore Paypal Sms Agent Email Facebook Twitter Servers Bookstore Paypal Sms - Email Facebook Twitter Can We Avoid Building one Client per Server and Vice Versa?
  18. 18. DeepGraphs Generic Server Implementations • 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. 19. API Designer http://api-builder.tools.epu.ntua.gr/web/
  20. 20. DeepGraphs Generic AI Clients SW Interoperabilty Reasoning REST Multiple Servers Multiple Transactions
  21. 21. In APIs We Trust
  22. 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. 23. Dereferencable Rules on the 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. 24. Advances of the Methodology • 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. 25. Next Steps 1. First Release 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. 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.

Notas do Editor

  • 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
  • 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
  • API discoverability and documentation
    Reuse of state transition logic across clients
    Ease of client development
    More flexibility for servers to evolve
  • http://csunplugged.org/wp-content/uploads/2015/03/rowboat_0.png1286488551
    http://oldblogimages.metawrap.com/DFAsmall.png
  • http://cdn.makeuseof.com/wp-content/uploads/2011/09/ifttt-icon.png?92a7a3
  • https://lh3.ggpht.com/K2afaPvqzzq-36aXKmdVgniDGKy3bDURiuYRGcltAcIYoL9oABqIvU5hwtP0wlyOYA=h900

×