Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

Introduction

To set up the ENAPSO together free platform on your end and learn how to manage SPARQL templates effectively, please follow the instructions on this Confluence page. Once you have completed the setup, you can proceed with the steps below to create REST APIs for managing CRUD operations for each class.

This documentation provides a step-by-step guide to creating REST APIs for managing CRUD operations for each class using SPARQL templates on the ENAPSO together free platform. By following these instructions, you will be able to automate and enhance the interactivity of your Knowledge Graph through RESTful services.

Why Use Multiple REST Endpoints?

Accessing EBUCorePlus knowledge graphs via multiple REST endpoints, as opposed to a central SPARQL template endpoint, offers several key advantages:

REST Compliance

  • Standardized Methods: RESTful services use standard HTTP methods (GET, POST, PATCH, DELETE) to perform CRUD operations. This makes the API intuitive and easier to use, as developers are already familiar with these methods.

  • Statelessness: RESTful APIs are stateless, meaning each request from a client contains all the information needed to process the request. This simplifies the server design and improves scalability.

Security

  • Granular Access Control: Each REST endpoint can be individually secured, allowing you to enforce specific access permissions for different operations. This granular control helps prevent unauthorized access to sensitive data and ensures that only authorized users can perform certain actions.

  • Accurately Validating Input Parameters: By distributing functionality across multiple endpoints, you enhance the accuracy of input parameter validation. This approach minimizes the risk of improper data handling and helps maintain the integrity of the system, even if one endpoint encounters issues.

endpoint

  • Load Distribution: With multiple endpoints, you can distribute the load more effectively. Different endpoints can be scaled independently based on demand, leading to better performance and resource utilization.

Access the Swagger Documentation

Navigate to the View Management Service documentation in your web browser. This interface provides access to all the necessary endpoints for managing and executing SPARQL templates.

Managing REST API Endpoints via OpenAPI/Swagger

Create Endpoints for CRUD Operations

  1. Find the create-endpoint-4-template endpoint, which is used for setting up new REST APIs for each SPARQL template.

  2. Click on the "Try it out" button to enable interactive usage of this endpoint.

  3. Configure the Endpoint Details

    • In the records array, you will configure each CRUD operation as a separate object. Here’s how you can set up each endpoint for the EditorialObject class:

      {
          "records": [
              {
                  "endpoint": "editorialObject",
                  "baseURL": "/v1",
                  "endpointConfig": [
                      {
                          "method": "get",
                          "template": "readEditorialObject"
                      },
                      {
                          "method": "post",
                          "template": "createEditorialObject"
                      },
                      {
                          "method": "patch",
                          "template": "updateEditorialObject"
                      },
                      {
                          "method": "delete",
                          "template": "deleteEditorialObject"
                      }
                  ]
              }
          ]
      }
    • Variable Descriptions

      • records: This array holds one or more configuration objects. Each object defines a set of CRUD operations associated with a specific endpoint.

        • endpoint: This string specifies the name of the endpoint. It acts as a part of the URL path where the API will be accessible. For example, editorialObject results in a REST endpoint that could be accessed via ${baseURL}/editorialObject.

        • baseURL: This is the base path under which the endpoint will be grouped. For instance, /v1 indicates that the endpoint will be accessed under the version 1 group, forming part of the complete URL path. For example, http://localhost/enapso-dev/view-management${baseURL}/${endpoint} will become http://localhost/enapso-dev/view-management/v1/editorialObject.

        • endpointConfig: An array of objects where each object specifies a CRUD operation and the associated settings:

          • method: The HTTP method (e.g., get, post, patch, delete) that determines what kind of operation this endpoint will perform. This corresponds to the CRUD operation:

            • get for reading or retrieving data,

            • post for creating new data,

            • patch for updating existing data,

            • delete for removing data.

          • template: The name of the SPARQL template that will be executed when this endpoint is called. It ties the REST API directly to a predefined SPARQL operation within the database management system.

  4. After entering all the necessary details, click on the Execute button. A successful request will create REST endpoints for each configured operation.

    create-endpoint-request.png

  5. The response will indicate success, confirming that the endpoints are now set up and ready for use.

    create-endpoint-request-response.png

Removing REST API endpoints via OpenAPI

  1. Find the delete-endpoint-of-template endpoint, which is used for removing existing REST APIs of each SPARQL template.

  2. Click on the "Try it out" button to enable interactive usage of this endpoint.

  3. Configure the Endpoint Details

    • In the records array, you will configure each CRUD operation as a separate object. Here’s how you can remove REST endpoints of the EditorialObject class:

      {
          "records": [
              {
                  "endpoint": "editorialObject",
                  "baseURL": "/v1",
                  "endpointConfig": [
                      {
                          "method": "get",
                          "template": "readEditorialObject"
                      },
                      {
                          "method": "post",
                          "template": "createEditorialObject"
                      },
                      {
                          "method": "patch",
                          "template": "updateEditorialObject"
                      },
                      {
                          "method": "delete",
                          "template": "deleteEditorialObject"
                      }
                  ]
              }
          ]
      }
    • Variable Descriptions

      • records: This array holds one or more configuration objects.

        • endpoint: This string specifies the name of the endpoint. It acts as a part of the URL path where the API is accessible. For example, editorialObject results in a REST endpoint that could be accessed via ${baseURL}/editorialObject.

        • baseURL: This is the base path under which the endpoint is grouped. For instance, "/v1" indicates that the endpoint is to be accessed under the version 1 group, forming part of the complete URL path. For example, <http://localhost/enapso-dev/view-management${baseURL}/${endpoint}> will become <http://localhost/enapso-dev/view-management/v1/editorialObject.>

        • endpointConfig: An array of objects where each object specifies a CRUD operation and the associated template that needs to be removed.

          • method: The HTTP method (e.g., get, post, patch, delete) that determines what kind of operation needs to be removed. This corresponds to the CRUD operation:

            • get for reading or retrieving data,

            • post for creating new data,

            • patch for updating existing data,

            • delete for removing data.

          • template: The name of the SPARQL template as we create one method for each template name which is called when we send a request on that REST method so as to remove that method.

  4. After entering all the necessary details, click on the "Execute" button. A successful request will create REST endpoints for each configured operation.

    delete-endpoint-request.png

  5. The response will indicate success, confirming that the endpoints are removed.

    delete-endpoint-request-response.png

Managing REST API Endpoints via Command Line (curl)

Executing HTTP Requests via the Command Line

Opens your command line interface. This process varies depending on your operating system:

  • Windows: Open Command Prompt.

  • macOS or Linux: Open Terminal.

Once your command line interface is open, you can execute the curl commands to interact with the REST API. Here are detailed instructions on how to execute these commands for creating, reading, updating, and deleting Editorial Objects:

1. Create (POST)

To create a new EditorialObject, use the following curl command to send a POST request:

curl -X POST "http://localhost/enapso-dev/view-management/v1/editorialObject" -H "Content-Type: application/json" -d "{\"variables\": {\"iri\": \"http://ont.enapso.com/sparql-template#EditorialObject_2f9b1462-e937-4416-8c23-ce96fc42dc55\", \"title\": \"Never Look Away\", \"shotLog\": \"Visual storytelling that captures the protagonist artistic journey and the tumultuous history of Germany.\"}}"
create-request.png

This command sends the data to create a new instance of an EditorialObject.

2. Read (GET)

To retrieve information of EditorialObject instances, use the following curl command to send a GETrequest

Basic GET Request

To retrieve information about EditorialObject instances, you can use the following curl command:

curl -X GET http://localhost/enapso-dev/view-management/v1/editorialObject
read-request.png

Passing Limit and Offset Parameters

To retrieve information about EditorialObject instances with limit and offset parameters, The limit parameter specifies the maximum number of results to return, while the offset parameter specifies the starting point in the list of results, effectively skipping the first offset number of results. you can use the following curl command:

curl --get "http://localhost/enapso-dev/view-management/v1/editorialObject?limit=10&offset=10"

Passing Filters

You can pass filters using the filter.propertyName=value format in the query parameters. For example, if the property IRI is http://www.ebu.ch/metadata/ontologies/ebucoreplus#title, you will use the property name title after the hash.

Since the ebucoreplus ontology primarily involves parent-to-child relationships, most filters will be based on these relationships. However, if you want to filter based on child-to-parent relationships, you can also do that. For this, you need to pass the property name with the complete IRI enclosed in angle brackets (<>). The filter will be applied accordingly.

1. Filtering by a Property

To filter EditorialObject instances where the property titleis Das Boot, you would use:

curl --get "http://localhost/enapso-dev/view-management/v1/editorialObject"   --data-urlencode "filter.title=Das Boot"
Screenshot 2024-05-16 133706.png
2. Filtering by a Property with a Full IRI (Child to Parent)

In ebucorepus ontologies, relationships are defined from a parent entity to a child entity. However, there are cases where we need to filter entities based on relationships defined in the opposite direction, i.e., from child to parent. This is known as a child-to-parent relationship.

In such scenarios, we apply filters based on the property defined in the child entity that points to the parent entity. To do this, we use the full IRI (Internationalized Resource Identifier) of the property and the specific IRI of the child entity we are interested in. By doing so, we can retrieve all parent entities that are connected to the specified child entity through the defined relationship.

Example of Child-to-Parent Relationship

Let's consider a practical example using an ontology for EditorialObjects and Assets.

In ebucorepus ontology:

  • An Asset has a property hasRelatedEditorialObject that links to EditorialObject.

Objective

We want to retrieve all EditorialObjects that are related to a specific Asset.

Steps

  1. Identify the property IRI that defines the relationship from the Asset to the EditorialObject. In this case, it is http://www.ebu.ch/metadata/ontologies/ebucoreplus#hasRelatedEditorialObject.

  2. Pass the full IRI of this property along with the IRI of the specific Asset we are interested in.

Example

To filter EditorialObject instances based on a relationship property (child-to-parent) that requires the full IRI of the property, such as <http://www.ebu.ch/metadata/ontologies/ebucoreplus#hasRelatedEditorialObject> you would use

curl --get "http://localhost/enapso-dev/view-management/v1/editorialObject"    --data-urlencode "filter.%3Chttp%3A%2F%2Fwww.ebu.ch%2Fmetadata%2Fontologies%2Febucoreplus%23hasRelatedEditorialObject%3E=http://www.ebu.ch/metadata/ontologies/ebucoreplus/data/Asset_37f6d90c-87c9-4c1f-9a46-ff1102f9bd8a"
Screenshot 2024-05-16 133956.png

Important Notes

  • Encoding URIs: When passing property IRI, ensure it is URL-encoded.

3. Detailed Example with Multiple Filters

Suppose you want to filter EditorialObject instances where:

  • The property title is Run Lola Run.

  • The child-to-parent (Asset to EditorialObject) property <http://www.ebu.ch/metadata/ontologies/ebucoreplus#hasRelatedEditorialObject> is http://www.ebu.ch/metadata/ontologies/ebucoreplus/data/Asset_37f6d90c-87c9-4c1f-9a46-ff1102f9bd8a.

curl --get "http://localhost/enapso-dev/view-management/v1/editorialObject"   --data-urlencode "filter.title=Run Lola Run"    --data-urlencode "filter.%3Chttp%3A%2F%2Fwww.ebu.ch%2Fmetadata%2Fontologies%2Febucoreplus%23hasRelatedEditorialObject%3E=http://www.ebu.ch/metadata/ontologies/ebucoreplus/data/Asset_37f6d90c-87c9-4c1f-9a46-ff1102f9bd8a"

Screenshot 2024-05-16 134257.png

3. Update (PATCH)

To update an existing EditorialObject, use the following curl command to send a PATCHrequest with the IRI and new values:

curl -X PATCH "http://localhost/enapso-dev/view-management/v1/editorialObject" -H "Content-Type: application/json" -d "{\"variables\": {\"iri\": \"http://ont.enapso.com/sparql-template#EditorialObject_2f9b1462-e937-4416-8c23-ce96fc42dc55\", \"productionSynopsis\": \"Directed by Florian Henckel von Donnersmarck, this sweeping historical drama delves into themes of art, love, tragedy, and the inescapable impact of politics on personal lives.\"}}"
update-request.png

This command updates the specified EditorialObject's productionSynopsisbased on its IRI.

4. Delete (DELETE)

To delete an EditorialObject instance, use the following curl command to send a DELETE request:

curl -X DELETE "http://localhost/enapso-dev/view-management/v1/editorialObject" -H "Content-Type: application/json" -d "{\"variables\": {\"iri\": \"http://ont.enapso.com/sparql-template#EditorialObject_2f9b1462-e937-4416-8c23-ce96fc42dc55\"}}"
delete-request.png

This command deletes the EditorialObject identified by the given IRI.

These curl commands provide a direct way to interact with your RESTful API, enabling you to perform create, read, update, and delete operations on EditorialObject

Summary

This setup enables you to fully utilize the RESTful interface of the ENAPSO together free platform, integrating seamlessly with your existing workflows and enhancing data manipulation capabilities through programmatically accessible endpoints. By following these steps, users can effectively create and manage REST APIs for CRUD operations, empowering them to perform sophisticated data interactions directly through HTTP requests.

  • No labels