diff --git a/development/404.html b/development/404.html new file mode 100644 index 00000000..39db7f9d --- /dev/null +++ b/development/404.html @@ -0,0 +1,2743 @@ + + + +
+ + + + + + + + + + + + + + + + + + +In ONE Record, parties can grant other parties access to their data (or parts of it). +The ONE Record standard allows parties to change or revoke these access rights to their data whenever they wish.
+Before an organization can access a LogisticsObject of another organization, it needs to be authorized to do so and the server that hosts the logistics objects will determine whether to grant access. +Typically, when an participant creates a LogisticsObject and makes it available via its ONE Record API, the IoL participant will share the URI of that LogisticsObject with another IoL participant and grant them access by default.
+For example, a freight forwarder creates a Shipment, grants read access to an airline, and then sends the URI of the Logistics Object via a ONE Record Notification or other channel to the airline.
+It might happen that the Airline needs access to additional Logistics objects linked to the Shipment (i.e.: Piece). In this case, the Airline MAY request the access delegation directly from the freight forwarder (Example A1)
+At this point, only the forwarder and the airline can access this specific LogisticsObjects, but no one else.
+However, if a ground handling agent (GHA) also needs access to this logistics object, the airline MAY request an access delegation for the GHA (Example A2).
+If, as in this presented scenario, the airline already has a delegation of access to the logistics object, the concept of Trust Chains takes effect.
+Note
+The party granting access is referred to as the Delegator
and the party receiving access is the Delegate
.
+The party requesting access is referred to as the Requestor
.
Guidelines for Access Delegations in ONE Record:
+The following HTTP header parameters MUST be present in the request:
+Header | +Description | +Examples | +
---|---|---|
Accept | +The content type that the ONE Record client wants the HTTP response to be formatted in. | +application/ld+json | +
Content-Type | +The content type that is contained with the HTTP body. Valid content types. | +application/ld+json | +
The HTTP request body must contain a valid AccessDelegation object in the format as specified by the Content-Type in the header.
+The AccessDelegation is a data class of the ONE Record API ontology. +The properties and relationships to other data classes are visualized in the diagram.
+classDiagram
+ direction LR
+
+ class LogisticsObject{
+ }
+
+ class Organization{
+ }
+ class AccessDelegation{
+ + hasDescription: xsd:string [0..1]
+ + hasPermission[]: Permission [1..*]
+ + isRequestedFor[]: Organization [1..*]
+ + notifyRequestStatusChange: xsd:boolean = FALSE
+ + hasLogisticsObject[]: LogisticsObject [1..*]
+ }
+
+ AccessDelegation "1" --> "1..*" Permission
+ AccessDelegation "1" --> "1..*" Organization: requestedFor
+ AccessDelegation "1" --> "1..*" LogisticsObject
+
+ class Permission{
+ <<Enumeration>>
+ GET_LOGISTICS_EVENT
+ GET_LOGISTICS_OBJECT
+ PATCH_LOGISTICS_OBJECT
+ POST_LOGISTICS_EVENT
+ }
+A successful request MUST return a HTTP/1.1 201 Created
status code and the following HTTP headers parameters MUST be present in the response:
Header | +Description | +Examples | +
---|---|---|
Location | +The URI of the newly created AccessDelegationRequest | +https://1r.example.com/action-requests/b6c24b63-405c-5cc3-ac88-9b109bb939ba | +
Type | +The type of the newly created AccessDelegationRequest as a URI | +https://onerecord.iata.org/ns/api#AccessDelegationRequest | +
The following HTTP status codes MUST be supported:
+Code | +Description | +Response body | +
---|---|---|
201 | +Request for delegation was successful | +No response body | +
400 | +Invalid Access Delegation object | +Error | +
401 | +Not authenticated | +Error | +
403 | +Not authorized to submit Delegation Request | +Error | +
415 | +Unsupported Content Type | +Error | +
500 | +Internal Server Error | +Error | +
To engage with the "Request Access Delegation" endpoint, a client needs proper authentication. If requests lack proper authentication, the ONE Record server should respond with a 401 "Not Authenticated"
status.
An organization requests an access delegation for itself for the Piece with the URI https://1r.example.com/logistics-objects/1a8ded38-1804-467c-a369-81a411416b7c
+Request:
+POST /access-delegations HTTP/1.1
+Content-Type: application/ld+json; version=2.0.0-dev
+Accept: application/ld+json; version=2.0.0-dev
+
+{
+ "@context": {
+ "cargo": "https://onerecord.iata.org/ns/cargo#",
+ "api": "https://onerecord.iata.org/ns/api#"
+ },
+ "@type": "api:AccessDelegation",
+ "api:hasDescription": "Require access to Piece for handling",
+ "api:hasPermission": [{
+ "@id": "api:GET_LOGISTICS_OBJECT"
+ }
+ ],
+ "api:isRequestedFor": [{
+ "@id": "https://1r.example.com/logistics-objects/Airline_XYZ"
+ }],
+ "api:notifyRequestStatusChange": false,
+ "api:hasLogisticsObject": [{
+ "@id": "https://1r.example.com/logistics-objects/1a8ded38-1804-467c-a369-81a411416b7c"
+ }]
+}
+
Response: +
HTTP/1.1 201 Created
+Location: https://1r.example.com/action-requests/b6c24b63-405c-5cc3-ac88-9b109bb939ba
+Content-Type: application/ld+json; version=2.0.0-dev
+Type: https://onerecord.iata.org/ns/api#AccessDelegationRequest
+
Note
+The Requestor
linked the isRequestedBy property in the created AccessDelegationRequest
+and the Delegate
linked in the isRequestedFor property in the AccessDelegation are the same.
An organization requests an access delegation for a business partner for the Piece with the URI https://1r.example.com/logistics-objects/1a8ded38-1804-467c-a369-81a411416b7c
+Request:
+POST /access-delegations HTTP/1.1
+Content-Type: application/ld+json; version=2.0.0-dev
+Accept: application/ld+json; version=2.0.0-dev
+
+{
+ "@context": {
+ "cargo": "https://onerecord.iata.org/ns/cargo#",
+ "api": "https://onerecord.iata.org/ns/api#"
+ },
+ "@type": "api:AccessDelegation",
+ "api:hasDescription": "Our GHA requires read access to Piece for handling",
+ "api:hasPermission": [{
+ "@id": "api:GET_LOGISTICS_OBJECT"
+ }
+ ],
+ "api:isRequestedFor": [{
+ "@id": "https://1r.example.com/logistics-objects/GHA_ABC"
+ }],
+ "api:notifyRequestStatusChange": false,
+ "api:hasLogisticsObject": [{
+ "@id": "https://1r.example.com/logistics-objects/1a8ded38-1804-467c-a369-81a411416b7c"
+ }]
+}
+
Response: +
HTTP/1.1 201 Created
+Location: https://1r.example.com/action-requests/1d2d3807-5dd9-5b5b-acb6-26163a6d7411
+Content-Type: application/ld+json; version=2.0.0-dev
+Type: https://onerecord.iata.org/ns/api#AccessDelegationRequest
+
Note
+The Requestor
associated with the isRequestedBy property in the created AccessDelegationRequest
+is different from the Delegate
linked in the isRequestedFor property in the AccessDelegation. The Requestor
must be derived from the API authentication mechanism identifying who is making the request.
Trust chains are based on business partnerships and trust in the transport chain. +It ensures that the company who has shared a logistics object, always knows who MAY access the data and at any time, it can revoke all or part of the chain of trust.
+Therefore, the concept described in the previous sections can be used by organizations to delegate access to their partners, which become 3rd parties. +In the example above, the airline can request that the forwarder gives access to their ground handler. +The forwarder will grant the access on the basis that they trust the airline who trusts their ground handler.
+However, if the holder of the logistics object withdraws access delegation to a second party, it MUST be ensured that the third party's access delegation is also withdrawn.
+See also the section about revoking Action Requests.
+ + + + + + + + + + + + + +ONE Record uses a generic action request pattern to support the process of one organization requesting an action that must be approved by another organization.
+Examples include SubscriptionRequest, where the subscriber asks the publisher to subscribe him/her on a LogisticsObject; or the ChangeRequest,
+where a User of a LogisticsObject
submits a Change of a LogisticsObject that must be approved and applied by the Holder of the LogisticsObject
.
While the creation of Action Requests by submitting Change, Subscription or Access Delegation objects is described in the previous sections, this section describes the managing of Action Requests. +This enables users and holders to view and revoke action requests, and enables holders to change the status of an ActionRequest, i.e. to accept or reject.
+Guidelines for Action Requests in ONE Record:
+Holder of the LogisticsObject
Holder of the LogisticsObject
Holder of the LogisticsObject
SHOULD be accepted and processed directly.REQUEST_PENDING
status.Delegator
or the Delegate
Requestor
/Subscriber
or the Publisher
Requestor
or the Holder of the LogisticsObject
ActionRequest state diagram for AccessDelegationRequest, ChangeRequest, and SubscriptionRequest
+ stateDiagram-v2
+
+ direction LR
+
+ [*] --> REQUEST_PENDING
+
+ REQUEST_PENDING --> REQUEST_ACCEPTED: accepted by holder
+ REQUEST_PENDING --> REQUEST_REJECTED: rejected by holder
+ REQUEST_PENDING --> REQUEST_REVOKED: revocation requested
+
+ REQUEST_REVOKED --> [*]
+
+ REQUEST_ACCEPTED --> [*]
+ REQUEST_ACCEPTED --> REQUEST_FAILED: an error has occurred
+
+ REQUEST_FAILED --> [*]
+
+ REQUEST_REJECTED --> [*]
+ActionRequest state diagram for VerificationRequest
+ stateDiagram-v2
+
+ direction LR
+
+ [*] --> REQUEST_PENDING
+
+ REQUEST_PENDING --> REQUEST_ACKNOWLEDGED: acknowledged by holder
+ REQUEST_PENDING --> REQUEST_REJECTED: rejected by holder
+ REQUEST_PENDING --> REQUEST_REVOKED: revocation requested
+ REQUEST_PENDING --> REQUEST_FAILED: revocation requested
+
+ REQUEST_REVOKED --> [*]
+
+ REQUEST_FAILED --> [*]
+
+ REQUEST_REJECTED --> [*]
+
+ REQUEST_ACKNOWLEDGED --> [*]
+ActionRequest data model
+The ActionRequest is a data class of the ONE Record API ontology. +The properties and relationships to other data classes are visualized in the following class diagram.
+ classDiagram
+
+ direction LR
+
+ class LogisticsObject{
+ }
+
+ class Organization{
+ }
+
+ class AccessDelegation{
+ + hasDescription: xsd:string [0..1]
+ + hasPermission[]: Permission [1..*]
+ + isRequestedFor[]: Organization [1..*]
+ + notifyRequestStatusChange: xsd:boolean = FALSE
+ + hasLogisticsObject[]: LogisticsObject [1..*]
+ }
+
+ AccessDelegation "1" --> "1..*" Permission
+ AccessDelegation "1" --> "1..*" Organization: requestedFor
+ AccessDelegation "1" --> "1..*" LogisticsObject
+
+ class ActionRequest {
+ <<Abstract>>
+ + hasError[]: Error [*]
+ + isRequestedAt: xsd:dateTime
+ + isRequestedBy: Organization
+ + isRevokedBy: Organization [0..1]
+ + hasRequestStatus: RequestStatus = REQUEST_PENDING
+ + isRevokedAt: xsd:dateTime [0..1]
+ }
+ ActionRequest <|-- AccessDelegationRequest
+ ActionRequest <|-- ChangeRequest
+ ActionRequest <|-- SubscriptionRequest
+
+ ActionRequest "1" --> "0..*" Error
+ ActionRequest "1" --> "1..*" Organization : requestedBy
+ ActionRequest --> RequestStatus
+ ActionRequest "1" --> "1..*" Organization : revokedBy
+
+ class AccessDelegationRequest{
+ + hasAccessDelegation: AccessDelegation
+ }
+ AccessDelegationRequest "1" --> "1" AccessDelegation
+
+ class ChangeRequest{
+ + hasChange: Change
+ }
+ ChangeRequest "1" --> "1" Change
+
+ class SubscriptionRequest{
+ + hasSubscription: Subscription
+ }
+ SubscriptionRequest "1" --> "1" Subscription
+
+ class VerificationRequest{
+ + hasVerification: Verification
+ }
+ VerificationRequest"1" --> "1" Verification
+
+ class Change{
+ + hasDescription: xsd:string [0..1]
+ + hasOperation[]: Operation [1..*]
+ + hasLogisticsObject: LogisticsObject
+ + hasRevision: xsd:positiveInteger
+ + notifyRequestStatusChange: xsd:boolean = FALSE
+ }
+ Change "1" --> "1" LogisticsObject
+ Change "1" --> "1..*" Operation
+
+ class Subscription{
+ + hasContentType[]: xsd:string [*]
+ + hasDescription: xsd:string [0..1]
+ + expiresAt: xsd:dateTime [0..1]
+ + hasSubscriber: Organization
+ + hasTopicType: TopicType
+ + notifyRequestStatusChange: xsd:boolean = FALSE
+ + sendLogisticsObjectBody: xsd:boolean = FALSE
+ + includeSubscriptionEventType[]: SubscriptionEventType [1..*]
+ + hasTopic: xsd:anyURI
+ }
+ Subscription "1" --> "1" Organization: hasSubscriber
+ Subscription --> TopicType
+ Subscription "1" --> "1..*" SubscriptionEventType
+
+ class Verification{
+ + hasLogisticsObject: LogisticsObject
+ + hasError[]: Error[1..*]
+ + hasRevision: xsd:positiveInteger
+ + notifyRequestStatusChange: xsd:boolean = FALSE
+ }
+ Verification "1" --> "1" LogisticsObject
+ Verification "1" --> "1..*" Error
+
+ class RequestStatus{
+ <<Enumeration>>
+ REQUEST_PENDING
+ REQUEST_ACCEPTED
+ REQUEST_ACKNOWLEDGED
+ REQUEST_REJECTED
+ REQUEST_FAILED
+ REQUEST_REVOKED
+ }
+
+ class SubscriptionEventType{
+ <<Enumeration>>
+ LOGISTICS_OBJECT_CREATED
+ LOGISTICS_OBJECT_UPDATED
+
+ LOGISTICS_EVENT_RECEIVED
+ }
+The following HTTP header parameters MUST be present in the request:
+Header | +Description | +Examples | +
---|---|---|
Accept | +The content type that a ONE Record client wants the HTTP response to be formatted in. This SHOULD include the version of the ONE Record API, otherwise the latest supported ONE Record API MAY be applied. | +
|
+
A successful request MUST return a HTTP/1.1 200 OK
status code.
+The body of the response includes the Action Request in the RDF serialization format that has been requested in the Accept
header of the request.
The following HTTP headers parameters MUST be present in the response:
+Header | +Description | +Example | +
---|---|---|
Content-Type | +The content type that is contained with the HTTP body. | +application/ld+json | +
Content-Language | +Describes the language(s) for which the requested resource is intended. | +en-US | +
Type | +The type of the Action Request as a URI | +https://onerecord.iata.org/ns/api#SubscriptionRequest | +
Last-Modified | +he date and time of the most recent change to the Action Request. Syntax: Last-Modified: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT . See https://developer.mozilla.org/en-US/docs/Web/ |
+Tue, 21 Feb 2023 07:28:00 GMT | +
The following HTTP status codes MUST be supported:
+Code | +Description | +Response body | +
---|---|---|
200 | +The request to retrieve the Action Request has been successful | +Action Request | +
301 | +The URI of the Action Request has permanently changed. | +No response body | +
302 | +The URI of the Action Request has temporarily moved. | +No response body | +
401 | +Not authenticated | +Error | +
403 | +Not authorized to retrieve the Action Request | +Error | +
404 | +Action Request not found | +Error | +
415 | +Unsupported Content Type | +Error | +
500 | +Internal Server Error | +Error | +
To engage with the "Get Action Request Details" endpoint, a client needs proper authentication and authorization to access the designated resource. If requests lack proper authentication, the ONE Record server should respond with a 401 "Not Authenticated"
status. Conversely, for requests without proper authorization, a 403 "Not Authorized"
response should be provided.
Each SubscriptionRequest MUST have a URI that can be accessed by the requestor (subscriber) +and the publisher to obtain the current status of the request and subscription details.
+Request:
+GET /action-requests/599fea49-7287-42af-b441-1fa618d2aaed HTTP/1.1
+Host: 1r.example.com
+Accept: application/ld+json; version=2.0.0-dev
+
Response:
+HTTP/1.1 200 OK
+Content-Type: application/ld+json; version=2.0.0-dev
+Content-Language: en-US
+Location: https://1r.example.com/action-requests/599fea49-7287-42af-b441-1fa618d2aaed
+Type: https://onerecord.iata.org/ns/api#SubscriptionRequest
+Last-Modified: Tue, 21 Feb 2023 07:28:00 GMT
+
+{
+ "@context": {
+ "api": "https://onerecord.iata.org/ns/api#"
+ },
+ "@type": "api:SubscriptionRequest",
+ "@id": "https://1r.example.com/action-requests/599fea49-7287-42af-b441-1fa618d2aaed",
+ "api:hasSubscription": {
+ "@type": "api:Subscription",
+ "@id": "internal:84891422-0215-519b-b551-bfb41d0519cd",
+ "api:hasContentType": "application/ld+json",
+ "api:hasSubscriber": {
+ "@id": "https://1r.example.com/logistics-objects/957e2622-9d31-493b-8b8f-3c805064dbda"
+ },
+ "api:hasTopicType": {
+ "@id": "api:LOGISTICS_OBJECT_IDENTIFIER"
+ },
+ "api:includeSubscriptionEventType": [
+ {
+ "@id": "api:LOGISTICS_OBJECT_UPDATED"
+ },
+ {
+ "@id": "api:LOGISTICS_OBJECT_CREATED"
+ },
+ {
+ "@id": "api:LOGISTICS_EVENT_RECEIVED"
+ }
+ ],
+ "api:hasTopic": {
+ "@type": "http://www.w3.org/2001/XMLSchema#anyURI",
+ "@value": "https://1r.example.com/logistics-objects/1a8ded38-1804-467c-a369-81a411416b7c"
+ }
+ },
+ "api:isRequestedBy": {
+ "@id": "https://1r.example.com/logistics-objects/957e2622-9d31-493b-8b8f-3c805064dbda"
+ },
+ "api:hasRequestStatus": {
+ "@id": "api:REQUEST_PENDING"
+ },
+ "api:isRequestedAt": {
+ "@type": "http://www.w3.org/2001/XMLSchema#dateTime",
+ "@value": "2023-04-20T10:38:01.000Z"
+ }
+}
+
After requesting a Verification of a LogisticsObject (see Example A1 in Verifications), the requestor can retrieve the VerificationRequest to check the status.
+Request: +
GET /action-requests/e4cf1ea5-96fc-4025-be21-159b779e3200 HTTP/1.1
+Host: 1r.example.com
+Accept: application/ld+json; version=2.0.0-dev
+
Response:
+HTTP/1.1 200 OK
+Content-Type: application/ld+json; version=2.0.0-dev
+Content-Language: en-US
+Location: https://1r.example.com/action-requests/e4cf1ea5-96fc-4025-be21-159b779e3200
+Type: https://onerecord.iata.org/ns/api#VerificationRequest
+Last-Modified: Tue, 02 Jul 2024 10:45:00 GMT
+
+{
+ "@context":{
+ "api":"https://onerecord.iata.org/ns/api#"
+ },
+ "@type":"api:VerificationRequest",
+ "@id":"https://1r.example.com/action-requests/e4cf1ea5-96fc-4025-be21-159b779e3200",
+ "api:hasVerification":{
+ "@type":"api:Verification",
+ "api:hasLogisticsObject":{
+ "@id":"https://1r.example.com/logistics-objects/1a8ded38-1804-467c-a369-81a411416b7c"
+ },
+ "api:hasError":[
+ {
+ "@type":"api:Error",
+ "api:hasTitle":"Empty goodsDescription. Please use goodsDescription to specify the description of the cargo",
+ "api:hasErrorDetail":{
+ "@type":"api:ErrorDetail",
+ "api:hasProperty":{
+ "@value":"https: //onerecord.iata.org/ns/cargo#goodsDescription",
+ "@type":"xsd:anyURI"
+ }
+ }
+ }
+ ],
+ "api:hasRevision":{
+ "@type":"http: //www.w3.org/2001/XMLSchema#positiveInteger",
+ "@value":"1"
+ },
+ "api:notifyRequestStatusChange":true
+ },
+ "api:isRequestedBy":{
+ "@id":"https://1r.example.com/logistics-objects/957e2622-9d31-493b-8b8f-3c805064dbda"
+ },
+ "api:hasRequestStatus":{
+ "@id":"api:REQUEST_PENDING"
+ },
+ "api:isRequestedAt":{
+ "@type":"http://www.w3.org/2001/XMLSchema#dateTime",
+ "@value":"2024-01-20T10:38:01.000Z"
+ }
+ }
+
This API action can be used the holder/publisher of a Logistics Object to approve or reject a pending ActionRequest.
+For example, as a publisher, this API action is used to change the status of a received Subscription Request on a ONE Record server using the PATCH HTTP method.
+Note
+Although the updating the state of of a Subscription Request is specified in the ONE Record API specification, it is not required to expose an API endpoint for this API action to be compliant with the ONE Record standard. +The reason for this is that only the holder of the logistics object MAY accept or reject a subscription request with any business logic or technology.
+Nevertheless, this API action specification is included for reference, because in many cases, the use of HTTP PATCH is the preferred solution to update resources with REST APIs.
+The following query parameters MUST be supported:
+Query parameter | +Description | +Valid values | +
---|---|---|
status | +A parameter used to configure the status of an Action request. This operation modifies the status of the Action Request based on the value specified in the status parameter. | +
|
+
The following HTTP header parameters MUST be present in the request:
+Header | +Description | +Examples | +
---|---|---|
Accept | +The content type that a ONE Record client wants the HTTP response to be formatted in. This SHOULD include the version of the ONE Record API, otherwise the latest supported ONE Record API MAY be applied. | +
|
+
Content-Type | +The content type that is contained with the HTTP body. | +
|
+
A successful request MUST return a HTTP/1.1 204 No Content
status code and the following HTTP headers parameters MUST be present in the response:
Header | +Description | +Example | +
---|---|---|
Location | +The URI of the Action Request | +https://1r.example.com/action-requests/6b948f9b-b812-46ed-be39-4501453da99b | +
Type | +The type of the Action Request as a URI | +https://onerecord.iata.org/ns/api#ChangeRequest | +
Otherwise, an Error
object with ErrorDetail
as response body MUST be returned with the following HTTP headers:
Header | +Description | +Example | +
---|---|---|
Content-Type | +The content type that is contained with the HTTP body. | +application/ld+json | +
Content-Language | +Describes the language(s) for which the requested resource is intended. | +en-US | +
The following HTTP status codes MUST be supported:
+Code | +Description | +Response body | +
---|---|---|
204 | +The Action Request was successfully updated | +No body required | +
400 | +The update request body is invalid | +Error | +
401 | +Not authenticated | +Error | +
403 | +Not authorized to update the Action Request | +Error | +
404 | +Action Request not found | +Error | +
415 | +Unsupported Content Type, response when the client sends a PATCH document format that the server does not support for the resource identified by the Request-URI. | +Error | +
422 | +Unprocessable request, when the server understands the PATCH document and the syntax of the PATCH document appears to be valid, but the server is incapable of processing the request. | +Error | +
500 | +Internal Server Error | +Error | +
Access to the Action Request update endpoint should be restricted to internal usage only, and it must not be made available to external entities.
+Request:
+PATCH /action-requests/733ed391-ad11-4c02-a2bf-c77ee7997c28?status=https://onerecord.iata.org/ns/api#REQUEST_ACCEPTED HTTP/1.1
+Host: 1r.example.com
+Content-Type: application/ld+json; version=2.0.0-dev
+Accept: application/ld+json; version=2.0.0-dev
+
Response:
+HTTP/1.1 204 No Content
+Content-Type: application/ld+json; version=2.0.0-dev
+Type: https://onerecord.iata.org/ns/api#SubscriptionRequest
+Location: https://1r.example.com/action-requests/733ed391-ad11-4c02-a2bf-c77ee7997c28
+
This API action MUST be used to revoke an Action Request MUST be revoked only by the original requestor of the ActionRequest or the holder/publisher of the Logistics Object.
+Revoking an Action Rquest does not require any mandatory HTTP headers.
+A successful request MUST return a HTTP/1.1 204 No Content
status code.
The following HTTP status codes MUST be supported:
+Code | +Description | +Response body | +
---|---|---|
204 | +The Action Request was successfully deleted | +No body required | +
401 | +Not authenticated | +Error | +
403 | +Not authorized to update the Action Request | +Error | +
404 | +Action Request not found | +Error | +
500 | +Internal Server Error | +Error | +
To engage with the "Revoke Action Request" endpoint, a client needs proper authentication and authorization to access the designated resource. If requests lack proper authentication, the ONE Record server should respond with a 401 "Not Authenticated"
status. Conversely, for requests without proper authorization, a 403 "Not Authorized"
response should be provided.
Request: +
+Response: +
+ + + + + + + + + + + + + +The following features summarize all of the ONE Record API features
+Get ONE Record Server Information Anyone who has access to a ONE Record server can retrieve the technical server meta information that contains information about supported features, supported ONE Record API version, supported ONE Record data model version, etc.
+Create and publish a Logistics Object - Anyone who controls a ONE Record server can create a new Logistics Object based on the ONE Record data model specification. Once created the Logistics Object is associated with a unique URI that makes the Logistics Object available on the network.
+Read a Logistics Object - Logistics Objects can be retrieved by calling the URI of that Logistics Object - its Logistics Object URI. Access rights to that Logistics Object URI is managed by the Holder of the Logistics Object.
+Update a Logistics Object - As a fundamental principle, only the Holder of a Logistics Object can make changes to it. Therefore, changes required by other parties are expressed as Change Requests
that needs to be approved and executed by the actual holder.
Subscribe to a Logistics Object for updates - Once a Logistics Object has been created, the holder can propose subscriptions to other parties who will then be notified of any changes. Other parties may also request such a subscription at the discretion of the holder.
+Create Logistics Event linked with Logistics Objects - Logistics Events like "arrival", "acceptance" etc. are central in the management of logistics and transport. Every participant in the network with sufficient access rights can submit any type of Logistics Event to any published Logistics Object.
+Read Logistics Event linked to a Logistics Object - Every participant of the network with sufficient permissions, can also query the Logistics Events associated with a Logistics Object.
+Manage access to a Logistics Object - Another fundamental principle of ONE Record is that only holders of Logistics Objects have fully control access rights to that Logistics Object. Therefore, only the holder of a Logistics Object can delegate permissions to users of the Logistics Object.
+Delegate access to a Logistics Object to a third party - By default, most Logistics Objects are not public accessible. Most of the time, access is granted to specific parties. Should these parties need to delegate access to further stakeholders - because they require data access to fulfil their logistics activities- then there is a mechanism for requesting such access to the holder of the Logistics Object.
+Manage and access versions of Logistics Objects - Each time a logistics object is updated by a change in data, this change is recorded in an audit trail. This automatically creates a new version of the Logistics Object. Each version of the logistics object SHOULD be found and retrieved.
+API security - Although not strictly an API feature, ONE Record specifies security measures for implementation on web servers such that access to the server may be identified, authenticated and authorized.
+HTTP Methods | +API Endpoint | +API Function | +
---|---|---|
GET | +/ | +Retrieve ServerInformation | +
POST | +/logistics-objects/ | +Create Logistics Object. This endpoint could be either internal or not implemented. | +
GET, PATCH | +/logistics-objects/{logisticsObjectId} | +Retrieve Logistics Object and links to related resources | +
GET | +/logistics-objects/{logisticsObjectId}/audit-trail | +Retrieve Audit Trail of a Logistics Object | +
GET, POST | +/logistics-objects/{logisticsObjectId}/logistics-events | +Create or retrieve LogisticsEvents to a Logistics Object | +
GET | +/logistics-objects/{logisticsObjectId}/logistics-events/{LogisticsEvent URI} | +Retrieve a LogisticsEvent | +
GET, POST | +/subscriptions | +Create or retrieve Subscription information for a Logistics Object type or a specific LogisticsObjectIdentifier | +
GET, PATCH, DELETE | +/action-requests | +Create, retrieve, or update Action Request (i.e. SubscriptionRequests, ChangeRequests or AccessDelegationRequests) | +
POST | +/notifications | +Receive Notifications | +
POST | +/access-delegations | +Create, retrieve, or update Access Delegation Request | +
Version: 2.0.0 Status: Endorsed by COTB on December 2023
+classDiagram
+ direction LR
+
+ class LogisticsObject{
+ }
+
+ class Organization{
+ }
+
+ class AccessDelegation{
+ + hasDescription: xsd:string [0..1]
+ + hasPermission[]: Permission [1..*]
+ + isRequestedFor[]: Organization [1..*]
+ + notifyRequestStatusChange: xsd:boolean = FALSE
+ + hasLogisticsObject[]: LogisticsObject [1..*]
+ }
+
+ AccessDelegation "1" --> "1..*" Permission
+ AccessDelegation "1" --> "1..*" Organization: requestedFor
+ AccessDelegation "1" --> "1..*" LogisticsObject
+
+ class ActionRequest {
+ <<Abstract>>
+ + hasError[]: Error [*]
+ + isRequestedAt: xsd:dateTime
+ + isRequestedBy: Organization
+ + isRevokedBy: Organization [0..1]
+ + hasRequestStatus: RequestStatus = REQUEST_PENDING
+ + isRevokedAt: xsd:dateTime [0..1]
+ }
+ ActionRequest <|-- AccessDelegationRequest
+ ActionRequest <|-- ChangeRequest
+ ActionRequest <|-- SubscriptionRequest
+
+ ActionRequest "1" --> "0..*" Error
+ ActionRequest "1" --> "1..*" Organization : requestedBy
+ ActionRequest --> RequestStatus
+ ActionRequest "1" --> "1..*" Organization : revokedBy
+
+ class AccessDelegationRequest{
+ + hasAccessDelegation: AccessDelegation
+ }
+ AccessDelegationRequest "1" --> "1" AccessDelegation
+
+ class ChangeRequest{
+ + hasChange: Change
+ }
+ ChangeRequest "1" --> "1" LogisticsObject
+ ChangeRequest "1" --> "1" Change
+
+ class SubscriptionRequest{
+ + hasSubscription: Subscription
+ }
+ SubscriptionRequest "1" --> "1" Subscription
+
+ class AuditTrail{
+ + hasChangeRequest[]: ChangeRequest [*]
+ + hasLatestRevision: xsd:positiveInteger
+ }
+ AuditTrail "1" --> "*" ChangeRequest
+
+ class Change{
+ + hasDescription: xsd:string [0..1]
+ + hasOperation[]: Operation [1..*]
+ + hasLogisticsObject: LogisticsObject
+ + hasRevision: xsd:positiveInteger
+ + notifyRequestStatusChange: xsd:boolean = FALSE
+ }
+ Change "1" --> "1" LogisticsObject
+ Change "1" --> "1..*" Operation
+
+ class Collection{
+ + hasItem: Object [0..*]
+ + hasTotalItems: xsd:nonNegativeInteger [0..1]
+ }
+
+ class Error{
+ + hasErrorDetail[]: ErrorDetail [1..*]
+ + hasTitle: xsd:string
+ }
+ Error "1" --> "*" ErrorDetail
+
+ class ErrorDetail{
+ + hasCode: xsd:string [0..1]
+ + hasMessage: xsd:string [0..1]
+ + hasProperty: xsd:anyURI [0..1]
+ + hasResource: xsd:anyURI [0..1]
+ }
+
+ class Notification{
+ + hasChangedProperty[]: xsd:anyURI [*]
+ + hasEventType: NotificationEventType
+ + isTriggeredBy: ActionRequest [0..1]
+ + hasLogisticsObject: LogisticsObject [0..1]
+ + hasLogisticsObjectType: xsd:anyURI [0..1]
+ }
+ Notification "1"--> "0..1" LogisticsObject
+ Notification "1" --> "1" NotificationEventType
+ Notification "1" --> "0..1" ActionRequest
+
+ class Operation{
+ + o: OperationObject
+ + op: PatchOperation
+ + p: xsd:anyURI
+ + s: xsd:string
+ }
+ Operation "1" --> "1" OperationObject
+ Operation --> PatchOperation
+
+ class OperationObject{
+ + hasDatatype: xsd:anyURI
+ + hasValue: xsd:string
+ }
+
+ class ServerInformation{
+ + hasDataHolder: Organization
+ + hasServerEndpoint: xsd:anyURI
+ + hasSupportedApiVersion[]: xsd:string [1..*]
+ + hasSupportedContentType[]: xsd:string [1..*]
+ + hasSupportedEncoding[]: xsd:string [*]
+ + hasSupportedLanguage[]: xsd:string [1..*]
+ + hasSupportedOntology[]: xsd:anyURI [1..*]
+ + hasSupportedOntologyVersion[]: xsd:anyURI [1..*]
+ }
+ ServerInformation "1" --> "1" Organization
+
+ class Subscription{
+ + hasContentType[]: xsd:string [*]
+ + hasDescription: xsd:string [0..1]
+ + expiresAt: xsd:dateTime [0..1]
+ + hasSubscriber: Organization
+ + hasTopicType: TopicType
+ + notifyRequestStatusChange: xsd:boolean = FALSE
+ + sendLogisticsObjectBody: xsd:boolean = FALSE
+ + includeSubscriptionEventType[]: SubscriptionEventType [1..*]
+ + hasTopic: xsd:anyURI
+ }
+ Subscription "1" --> "1" Organization: hasSubscriber
+ Subscription --> TopicType
+ Subscription "1" --> "1..*" SubscriptionEventType
+
+ class NotificationEventType{
+ <<Enumeration>>
+ LOGISTICS_OBJECT_CREATED
+ LOGISTICS_OBJECT_UPDATED
+
+ LOGISTICS_EVENT_RECEIVED
+
+ CHANGE_REQUEST_PENDING
+ CHANGE_REQUEST_ACCEPTED
+ CHANGE_REQUEST_REJECTED
+ CHANGE_REQUEST_FAILED
+ CHANGE_REQUEST_REVOKED
+
+
+ ACCESS_DELEGATION_REQUEST_PENDING
+ ACCESS_DELEGATION_REQUEST_ACCEPTED
+ ACCESS_DELEGATION_REQUEST_REJECTED
+ ACCESS_DELEGATION_REQUEST_FAILED
+ ACCESS_DELEGATION_REQUEST_REVOKED
+
+ SUBSCRIPTION_REQUEST_PENDING
+ SUBSCRIPTION_REQUEST_ACCEPTED
+ SUBSCRIPTION_REQUEST_REJECTED
+ SUBSCRIPTION_REQUEST_FAILED
+ SUBSCRIPTION_REQUEST_REVOKED
+ }
+ class PatchOperation{
+ <<Enumeration>>
+ ADD
+ DELETE
+ }
+ class Permission{
+ <<Enumeration>>
+ GET_LOGISTICS_EVENT
+ GET_LOGISTICS_OBJECT
+ PATCH_LOGISTICS_OBJECT
+ POST_LOGISTICS_EVENT
+ }
+ class TopicType{
+ <<Enumeration>>
+ LOGISTICS_OBJECT_TYPE
+ LOGISTICS_OBJECT_URI
+ }
+ class RequestStatus{
+ <<Enumeration>>
+ REQUEST_PENDING
+ REQUEST_ACCEPTED
+ REQUEST_REJECTED
+ REQUEST_FAILED
+ REQUEST_REVOKED
+ }
+ class SubscriptionEventType{
+ <<Enumeration>>
+ LOGISTICS_OBJECT_CREATED
+ LOGISTICS_OBJECT_UPDATED
+
+ LOGISTICS_EVENT_RECEIVED
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+