I'm building a new application and in order to not reinvent the wheel I' d like to re-use the vocabulary and tree model proposed on Schema.org.
For eg, I' dlike to implement a crud for Organization, + create and attach an Offer to it.
However, I'm not sure to see how to start :
Would it be possible to generate automatically an object model tree (java/ javascript) from a json-ld representation ?
Is there any kind of existing framework that already feed the gaps between the Schema.org models / web display / crud operation / REST api creation ?
Could you please point me to the right direction ?
Thanks
Perhaps you should have a look at https://api-platform.com/ It is a framework to build Web APIs based on JSON-LD, Schema.org and Hydra.
Related
I am looking for an easy-to-implement solution for form-based ontology editing and I wonder if there are any active projects and which of them is the right path to follow.
I need to create instances of an ontology (lets call it ontology A) using forms (either web or desktop) and store them in a triple store (e.g. Virtuoso). I would like to hide as much details as possible regarding the ontological relationships between the entities defined in ontology A and provide a plain simple user interface for CRUD (Create-Retrieve-Update-Delete) operations based on the entity schema defined in ontology A.
For example, I have found two possible solutions in the protege ecosystem:
PropertyFormPortlet It is not a live feature in the current webprotege version.
facsimile project
As described in the respective paper this is a solution that has been implemented for a specific context. Therefore, adapting it to another domain would not be as straightforward as I would like.
I wonder, is there another solution (even out of the protege ecosystem) that could facilitate such a form-based ontology editing. Could somebody provide some guidance?
Just in case someone lands in this question, I write down my conclusions. Practically, none of which I tried worked, but still I found out some interesting things.
OpenLink Structured Data Editor:
OSDE is a browser plugin which aims at populating RDF graphs in the form of files, based on Linked Vocabularies. In my case it didn't work as my locally hosted ontology cannot play the role of a "Linked Vocabulary". However, OpenLink team said they will work on it.
OData2SPARQL:
In our test, the WebIDE did not manage to create the forms out of the box as suggested by the respective video tutorial. However, we managed to use OpenUI library as a client of the OData services automatically created by OData2SPARQL, providing a web service interface for our ontology.
Ontowiki:
In our test environment, OntoWiki partially worked. We could save data but there were some bugs when trying to add properties etc. OntoWiki developers said that they plan to refactor in order to actively support it in newer hosting settings, but this is not the case right now.
My customer wants me to create a specification for a future REST API by using Enterprise Architect (SparxSystems). The deliverable should be well formatted text (can be html, docx or rtf). A class diagram should give a picture of the message body.
The only thing I found so far was https://github.com/bayeslife/api-add-in , a plugin for EA to generate RAML and more. Does anybody have a better approach?
The presentation 'Modeling Microservices' by Sander Hoogendoorn contains some interesting slides about modeling a REST API in Enterprise Architect. The presentation is available on slideshare.net. The most interesting slide is slide #75. Here is the picture shown on that slide:
(Class and attribute names are in Dutch. Verklaring means Declaration and Verklaringen means Declarations. But the business behind this example is not relevant.)
It would be nice if someone would have a plugin for Enterprise Architect to convert these class diagrams into Swagger specs (Open API specs).
Update 2019/03/18
Use this plugin and guideline: https://sparxsystems.us/go/restapi/
Original answer
I'm using Enterprise Architect at this moment to model an API. For this projects you have users that are granted a budget to buy certain products. The model is not yet complete, but I'm adding it here as reference.
In EA I added some additional stereotypes: Path, Resource and Representation + a new datatype ParamQuery.
To model the API you create a new class diagram and start by the root of your API as a class of stereotype "Application". Next you add your Resources and Paths. For each Resource you add the necessary GET, POST, PUT etc. operations. If QueryParams are passed along in the string for the GET operations you add them as Parameters for the operation, but as type QueryParam (you need to create it the first time). For the messagebody of POST operations you add a parameter of the class type it represents.
Next you add the "representation" classes, used by the Resources.
I recommend you to use postmanerator service which generate documentation for API automatically just save the API Calls in postman in a collection and pass this collector to this service it generates the documentation for you postmanerator link:
postmanerator
I hope my answer would be useful
I developed a REST API with Play 2.2.0. Some controllers expose GET methods, other expose POST methods with authentication etc...
I developed the client using Play as well but I have a problem. How can I avoid duplicating the model layer between both applications ?
In the server application, I have a Model Country(code, name).
In the client I am able to list countries and create new ones.
Currently, I have a class Country in both sides. When I get countries I deserialize them. The problem is that if I add a field in Country in the server, I have to maintain the client as well.
How can I share the Country entity between applications ?
PS : I don't want to create a dependency between the API and the client, as the client could have been developed with another language or framework
Thanks
This is not very specific to play framework but is more of a general question. You either create reusable representations of the data in your protocol (the actual data structures you send between your nodes) and get a tight coupling in representation and language. Many projects does it like this, since they know they will have the same platform throghout their architecture.
The other option is to duplicate all of or only the parts of parsing/generating that each part of the architecture needs, this way you get a looser coupling and can use any language in the different parts.
There are also some data protocols/tools that will have a representation in a protocol specific way and then can generate representations in various programming languages.
So as you see, it's all about pros and cons - neither solution is "the right way (tm)" to do this, you will have to think about your specific system/architecture and what pros are most valuable and what cons are most costly to you.
Well I suggest to send to the client a template of what they should display, on the client with js take advantage of js template frameworks, so you can tell to the client how can show them, dynamic... if they want to override them well... more job
We can call them Rest component oriented...
well suggestions :)
should works!
Good day. I'm still learning GWT so please help me. I'm working on a project - Web Application with GWT on the Client Side. This app has lots of CRUD operations so I'd like to make a model for this. Can anyone suggest a prototype for my CRUD class?
CRUD on this app goes something like this:
When I clicked the Details button in a module, a popup will be shown that allows the user to do CRUD operations. This popup do have the module title, info on the selected item, and the buttons - Edit, New, Delete.
I have already finished building the base GUI for this project but I'm just starting to work on each module. I choose to begin on those module with CRUD operations. So, please help me and give your ideas on this project. Thanks in advance :)
Your question is a little bit general.
You probably have to deal with two questions which can be handled separately:
Communication with the backend.
GUI for CRUD operations
Communication with the backend:
It depends on which kind of backend you are using.
Java-backend:
For Java backends the recommended client-server communication protocol is RequestFactory.
Non-Java-backend: In case you are using a non-java backend (python, PHP, etc) you have to use RequestBuilder using JSON or XML (I would recommend JSON).
For mapping JSON/XML to DTO's and vice verca you can use different methods:
Third party tools like piriti which are based on GWT generators
Javascript Overlay Types (JSO)
GWT Autobean framework (which is used by RequestFactory btw).
GUI for CRUD operations
For mapping your DTOs to your UI and doing the CRUD operations you can do it either:
manually
with the Editor framework
I would recommend to use the Editor framework as it reduces the amount of boilerplate code
to move an object from your object graph to the UI and back.
The Editor framework works well with RequestFactory (RequestFactoryEditorDriver), Autobean (SimpleBeanEditorDriver) and Javascript Overlay Types.
I am developing the administration part of a site. It mostly consist of manipulating list of data such as:
Products
Suppliers
Tax profiles
...
I find the task of creating a controller that handle the CRUD operations of each model a little too repeating and prone to mistake from one controller to another.
I would still need to adapt some of these controller for additional operation, but not all.
Does someone know a proven approach for reducing the implication of controller for the usual CRUD operations?
One suggestion would be to look at tweaking the T4 template that is used to generate the scaffold methods. Check out Rob Conery's MVC Starter Site to see what he's done (look in /Web/CodeTemplates in the source for the general idea).
There are also some other MVC libraries out there such as FubuMVC that aim to cut down on code repetition, but it's not based on the actual ASP.NET MVC framework (and it's not really my thing).