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.
The Essentials of Digital Experience Monitoring_ A Comprehensive Guide.pdf
Adding Rules on Existing Hypermedia APIs
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. 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
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. Rules on the Web
dc:description
Rules
SWRL
Ruleml
RIF
Rule
Inference
Producing valid statements
within rule based system
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
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 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. 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. 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. 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.
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