In my understanding, ContextBroker provides two API models such as NGSI V1 / V2.
Regarding this options, How can I config the ContextBroker configuration?
For example:
Content-Type : application/json
Accep : application/json
http://example_location:1026/v1/queryContext
You don't need to select API version by configuration. CB supports both simultaneously so it is just a matter of "selecting" it by using the proper URL in RESTful operations:
Those URLs starting with /v1 belong to NGSIv1 version
Those URLs starting with /v2 belong to NGSIv2 version
My recommendation is use always version 2. Eventually v1 could be deprecated and removed from Orion in the future.
Maybe you find useful the following document which compares NGSIv1 vs NGSIv2 and shows how the latter is much more flexible, advanced and powerful.
Related
I've run into "application/x-amz-json-1.1" in making requests to AWS resources. Most recently, it became a problem that an API Gateway I was communicating with didn't like handling it (for whatever reason). This got me wondering what the benefit to using application/x-amz-json-1.1 instead of application/json for my requests is. And to my disappointment, AWS doesn't seem to have any documentation on this odd content type.
So I turn to SO: what is "application/x-amz-json" and how is it different from "application/json"?
Amazon does not specifically document what application/x-amz-json Content-Type is for, however there are protocol documentations on Smithy (an open source language for defining services and SDKs published by AWS):
AWS JSON 1.1 protocol
AWS JSON 1.0 protocol
Considering the question relates to the difference when used as Content-Type1 header to make requests, I think we can tell the difference is:
application/json is to request/receive JSON data without anything more specific
application/x-amz-json-1.1 (or other version) is also to request/receive JSON data and expect additional behaviors described in the docs above. (i.e. tell the server/client this is JSON plus additional elements)
I think application/x-amz-json can be thought as a sort of extension or a more specific way of doing application/json requests.
it became a problem that an API Gateway I was communicating with didn't like handling it (for whatever reason)
In the specific case of making PATCH, PUT and POST requests to AWS Amazon API Gateway, specifying Content-Type header application/x-amz-json-1.1 or other version seems to be required. As per related docs:
Content-Type (Conditional)
Specifies JSON and the version, for example, Content-Type: application/x-amz-json-1.0.
Condition: Required for PATCH, PUT and POST requests.
Maybe the server understands application/json as basic JSON but requires application/x-amz-json-1.1 to perform specific requests.
1 Content-Tye header being used to tell the server/client how to process our request
My configuration in "wiring view" has the following components:
NGSI-source: Monitored NGSI Attributes: position
NGSI Entity to Point: Coordinates attribute: position
And these boxes are connected to Map Viewer, but I can't see the points in the map. Could you please answer the following questions?
Where is the problem?
Should I change the name of the attributes?
Seems that your context broker instance doesn't support https notifications. You have to install Rush and configure your context broker for using it. See this post for more info.
Take into account that the "NGSI Source" operator uses subscriptions while other widgets and operators use plain request (like queries) that works without needing https notifications.
I've searched the repo + FiWare Wikis and was unable to find any detailed API documentation.
I saw this: http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Complex_Event_Processing_Open_RESTful_API_Specification
I'm running a CEP instance on Fiware Cloud, and keep getting 500's and 405's for the calls I'm trying.
Yet it often references the user guide for more details on each endpoint parameter. Is there a more recent version?
Last release was more than a year ago, according to that spec. Are the docs up to date with the latest API version?
Else I'll have to reverse-engineer the API...
PS: CEP instance is running # http://130.206.117.120:8080/
Let me know if there are some sanity checks I can make ;)
I'm also using CEP and for REST API I haven't found newer specs (from the doc you linked). However, I didn't have any problems getting the resources.
You can try
GET: http://130.206.117.120:8080/ProtonOnWebServerAdmin/resources/instances/ProtonOnWebServer
It shows state and definitions-url of the engine.
I found it helpful to browse through examples from engine also, or from tuts.
I saw that your instance uses DoSAttack definition and I have tried POSTing to engine: POST: http://130.206.117.120:8080/ProtonOnWebServer/rest/events, header: Content-Type: application/json, payload: {"Name":"TrafficReport","volume":"22"} and got 200 OK.
For more complex tasks (apart from REST API) this PAGE lists latest specs.
Hope it helps!
I know how to do it for views, for example:
http://127.0.0.1:8092/<my_bucket>/_design/all/_view/all?full_set=true&key=<my_document_key>&connection_timeout=60000
And I tried:
http://127.0.0.1:8091/contacts/hello
(after creating via the UI a document with the key hello).
And the response was "Not Found."
What am I doing wrong?
Thanks,
Michael
There is no REST API for retrieving documents by key. You can either write your own thin service layer that uses the client SDK internally, or as of Couchbase 4.0, use the N1QL REST API to get the document through a query by key:
SELECT * FROM bucket USE KEYS [docId];
You can read about using the N1QL service endpoint here: http://developer.couchbase.com/documentation/server/4.1/n1ql/n1ql-rest-api/index.html
(Edit: Changed N1QL syntax to actually work. Thanks Gerald.)
In following way we can access couchbase document
Syntax:
hostname:8091/pools/default/buckets/{bucketname}/docs/{docid}
http://localhost:8091/pools/default/buckets/Aggregation/docs/AvgSumAssuredByProduct
Where
To access bucket related, use api: http://localhost:8091/pools/default/buckets/
Bucket Name: Aggregation
docid : AvgSumAssuredByProduct
If you want to use it for development purpose then you can use CLI or admin console (UI).
In production you should ALWAYS use language specific client SDK. Couchbase SDKs are intelligent as they have details about cluster map. Client knows before hand about which node should be used for CRUD operation.
I'm new to REST Web based services and trying to understanding how the contract is created for JSON returned REST services.
From my understanding, any XML based SOAP/REST services will have a WSDL document.
What document is created for JSON based REST Services?
a REST web service doesn't have any auto explanation document like wsdl, you need to know how the webservice works, reading the documentation provided with it. Generally it works with common requests. Assuming that you have a products REST webservice, you could have:
GET /products -> read all products
GET /products/1 -> read the product 1
POST /products -> create a new product
PUT /products/1 -> update product 1
DELETE /products/1 -> delete product 1
but you have to know which parameters you need to send to any request. I hope I was clear...
Every HTTP response has metadata in HTTP headers. One of those HTTP headers is ContentType. The content type identifies a media type which is the contract that the response payload must conform to. The specifications for media types can be found here http://www.iana.org/assignments/media-types/media-types.xhtml
One of the major differences between SOAP and HTTP (as an application protocol) is that SOAP defines the contract at design time, whereas with HTTP the contract is specified in the response message so it can change over time. Therefore it is important for the client to read the content type on each response to know how to process the response.
There is WADL (http://en.wikipedia.org/wiki/Web_Application_Description_Language) although it is not so much used as WSDL for SOAP. REST services written in Java EE automatically generate it as .../application.wadl, PHP suppor is pretty poor as far as I know.
As the others mentioned a web service definition is not necessary for RESTful services, however if you want to create something similar for your API the industry standard is Swagger/OpenAPI, though GraphQL schemas are also becoming a defacto standard too.
There are also a few other options you can also explore (see wikipedia).
Here is a list of the most common options:
swagger.json or openapi.json files in the OpenAPI Spec
GraphQL Schemas with full spec here
Postman Collections which can be published online.
RAML
RSDL