I need to be able to send REST calls and save the returning payload to variables within the cookbook (using chef solo).
Calls are made in HTTPS
Need to be able to get returning cookie header in order to login to API
Is there such a community LWRP available? I am not aware of any built-in functionality within chef to allow this. (from what I've read http_request provider in chef does not answer the above criteria)
Resources (and thus LWRPs) don't really have output values. What you want is to just use the Chef::HTTP class:
val = Chef::HTTP.new('https://cmdb/').get('/')
Related
I want to mock api calls from my application, and host the mock, so my tests can work without calls to real api. There is a service called restbird which does exactly that, but it is far from ideal for me. If you want to collaborate you have to host the service by your self. Also it has some errors like not displaying history of calls, or when it sends server errors for no reason. I want a service more robust than this one.
The only service that I think might be a good fit is SwaggerHub, it seems robust, it has virtual servers, and overall it is very popular. But the only problem is that I cannot find a way to record api calls from my application. So how can I record api calls for SwaggerHub?
There does not currently exist any functionality within SwaggerHub itself to record API calls made from the Swagger UI module within the tool. This is a limitation of the open-source Swagger UI tool.
What I can recommend is you use the Swagger Inspector tool. The Swagger Inspector can be used to make API calls from a client, save both the request and the response, and even generate an OpenAPI file for you based off the request/responses. If you create an account and sign in, you can even save your API calls to a collection to use later.
Swagger Inspector: https://inspector.swagger.io/builder
It may also be worth considering using ReadyAPI's Virtualization module to handle this use case. With ReadyAPI Virtualization you can record transactions from a browser, build mock services from the recorded transaction or an existing API definition, and then host the mock service using VirtServer.
ReadyAPI is a part of SmartBears API lifecycle products, so there are integrations between the two tools. For instance, you can port APIs from Swaggerhub into ReadyAPI directly and you can use mock services built in ReadyAPI to do dynamic mocking in Swaggerhub.
You can find more information about ReadyAPI Virtualization here: https://smartbear.com/product/ready-api/api-virtualization/
I realise this is a very late response to this thread, but hopefully this information comes in handy.
I want to create a brand new REST API using MarkLogic 9.x.x but without using Roxy or Gradle. I want to point to a file which has list of customized endpoints in basic MarkLogic setup and then keep my customized logic in those modules.
I've gone through the REST API documentation to create one by using CURL so that we can use default APIs provided by MarkLogic.
Any detailed explanation is appreciated.
Management REST api is really your best friend here, it is designed for this purpose. However, creating scripts that make the appropriate REST calls can be cumbersome. ml-gradle can support you with that though. It can generate a shell-script with all curl-statements for you, which you could run as-is, or use as starting point to build out your own set of deploy scripts. For details see:
https://github.com/marklogic-community/ml-gradle/wiki/Generating-a-shell-script
HTH!
Have you considered using XQRS ?, you can create custom REST endpoints with ease using intuitive Function Annotations much like one would do with JAX-RS or Java Spring REST Services. It can be installed and used with or with-out Gradle.
You can keep your custom logic either in these REST functions, or you could write your custom logic in JavaScript code that you then import/invoke from these functions. XQRS provides you with total flexibility. You can make beautiful REST APIs with Human-Friendly URLs that sit directly on MarkLogic, taking complete control of the URL Path. It's solid as a rock and unit tested to death. It scales with MarkLogic - i.e. you add more MarkLogic e-nodes and you automatically scale your REST servers, it's totally free and open source. The project is actively maintained and support is available on GitHub. If you've got a Swagger/OpenAPI interface file, you can generate a MarkLogic Stub too which could save you a lot of time.
Functions simply become available as REST Services based on the Annotations you place on them - and you can pass query/form parameters, cookies and the request body via the Annotations. Check out this snippet for a sample flavour.
declare
%rest:path("/factory/warehouse/wheel/{$wheel-id}")
%rest:GET
function get-wheel($wheel-id as xs:string) {
fn:doc($wheel-id)
};
declare
%rest:path("/factory/warehouse/wheel/{$wheel-id}")
%rest:PUT("{$doc}")
%xdmp:update
function put-wheel($wheel-id as xs:string, $doc as document-node(element())) {
xdmp:document-insert($wheel-id, $doc, map:entry("collections", "wheels"))
};
declare
%rest:path("/factory/warehouse/wheel")
function list-wheels() {
<wheels>{
fn:collection("wheels")
}</wheels>
};
Both responses to date are correct and accurate and help, however the original question is self-answered.
I've gone through the REST API documentation to create one by using
CURL so that we can use default APIs provided by MarkLogic.
That is in fact the answer to your question as stated.
To manually deploy ML rest API, please follow below steps
Create Module DB
Create App Server
Provide details for Module DB, database, port, URL rewriter
Deploy xquery, xsl using qConsole
let URI = path of file
let path = xdmp:document-get($FilePath)
xdmp:document-insert($URI,$path,(), ())
where endpoints.xqy will contains defined custom endpoint for your rest API and internally you can call search:search function to call data from MarkLogic
module namespace endpoints="urn:overstory:rest:modules:endpoints";
declare namespace rest="http://marklogic.com/appservices/rest";
(: ---------------------------------------------------------------------- :)
declare private variable $endpoints as element(rest:options) :=
<request uri="^/getcontent$" endpoint="<xqy file" user-params="allow">
<http method="GET"/>
</request>
Hope this will help
I am currently evaluating the framework "wolkenkit" [1] for using it in an application. Within this application I will have a user interface for tenant-based data management. Only authenticated users will have access to this application.
Additionally there should be a public REST API following common standards and being callable by public (tenant security done with submission of a tenant-based API Key within the request headers).
As far as I have found out, the wolkenkit REST API does not seem to fit these standards in forms of HTTP verbs.
But as wolkenkit at all appears to me as a really flexible and easy-to-use framework, I wonder how to basically implement such a public API.
May it be e.g. a valid approach to create an own web application which internally connects to the wolkenkit backend? What about the additional performance overhead then?
[1] https://www.wolkenkit.io/
In addition to the answer of mattwagl, I would like to point out a few things that you may be interested in.
First of all, since wolkenkit is based on CQRS, the application has a separate API for writing and reading. That means, that if you send a command (whose intent is to change state) this goes to the write API. If you subscribe for events or run a query, this goes to the read API.
This again means, that if you send a command, it's up to the write side to respond to it. As the write side is not meant to return application state, all it says is basically: "Thanks, I have received the command." To get the actual result you have to wait for the appropriate event, which means subscribing to the read API.
In the wolkenkit documentation there is a nice diagram which shows this in a clear way:
If you now add a separate REST API (which actually fulfills the requirements of REST), this means that you need to handle waiting for the result internally. In other words: Clients in wolkenkit are always meant to be asynchronous, REST is not. Hence it's your job to handle the asynchronous behavior of the wolkenkit APIs in your REST API. I think that this is the hardest part.
Once you have done this, you will have a synchronous REST API, and of course it will have some overhead. But I think that since its overhead is limited to passing through and translating network requests, it should be negligible.
Oh, and finally, there is another thing that you have to watch out for: Since REST as it was meant originally relies on the HTTP verbs to transport semantics, you need to map GET / POST / PUT / DELETE to the semantic commands of wolkenkit. As long as this can be done 1:1, everything's fine – problems start when there are multiple commands that (technically speaking) do an UPDATE.
PS: I'm also one of the developers of wolkenkit.
PPS: However you are going to solve this, I would be highly interested to hear from you! It would be very great if you could share your experiences with us, as you are most probably not the last one with this idea. If you want to contact us, the easiest way would be via Slack.
wolkenkit applications can be accessed using an HTTP- and a Websocket-API. These APIs are both provided by the tailwind module that wolkenkit uses under the hood. In the tailwind repo you can find a very simple documentation of the available HTTP routes.
You're right, the wolkenkit HTTP-API is not a classic REST-API. It's more RPC-style which in our experience is a good fit for applications. There are only 3 routes that your clients/tenants need to support: /v1/command (POST) is used for issuing commands. The commands you post should follow the command schema. /v1/events (POST) can be used for streaming events to clients. These events will follow the event schema. Finally you have /v1/read/:modelType/:modelName (POST) to read models. You can simply use HTTPie to test these routes.
Authentication of these APIs is currently done using OpenID-Connect. There's a very detailed article on how to setup authentication using Auth0. I'm not quite sure if this fits your use-case but you could basically use any Authentication Service that follows this standard or that is able to issue JWT tokens.
Finally you could also build your own JavaScript client-SDK that runs inside browsers by building a module that uses the wolkenkit-client-js under the hood. This SDK can just use the same API as any other client to connect to your application.
Hope this helps.
PS: Please note that I am one of the authors of wolkenkit.
I am looking for a quick way to spin up a very simple REST api, for testing purposes.
Specifically I want to be able to handle CORS preflight requests (i.e need ability to handle the OPTIONS verb)
E.g: A service that spins up a temporary node instance with express and allows me to add request handlers and gives me a temporary url. Or the equivalent in another language (java, ruby, etc)
Maybe try https://code.runnable.com it allows you to quickly build and run whole express apps and it allows multiple different languages not just node.js.
I want to ask some questions about the REST call. I am the green for the REST call and I would like to like what is REST call and how to use the URL to send a REST call to the server. Can anyone give me some basic tutorial or link for my to reference?
Besides, if I want to send a REST call to the server, what should I do? Do I need to set something in the URL? or set something in the server? Thank you.
REST is just a software architecture style for exposing resources.
Use HTTP methods explicitly.
Be stateless.
Expose directory structure-like URIs.
Transfer XML, JavaScript Object Notation (JSON), or both.
A typical REST call to return information about customer 34456 could look like:
http://example.com/customer/34456
Have a look at the IBM tutorial for REST web services
REST is somewhat of a revival of old-school HTTP, where the actual HTTP verbs (commands) have semantic meaning. Til recently, apps that wanted to update stuff on the server would supply a form containing an 'action' variable and a bunch of data. The HTTP command would almost always be GET or POST, and would be almost irrelevant. (Though there's almost always been a proscription against using GET for operations that have side effects, in reality a lot of apps don't care about the command used.)
With REST, you might instead PUT /profiles/cHao and send an XML or JSON representation of the profile info. (Or rather, I would -- you would have to update your own profile. :) That'd involve logging in, usually through HTTP's built-in authentication mechanisms.) In the latter case, what you want to do is specified by the URL, and the request body is just the guts of the resource involved.
http://en.wikipedia.org/wiki/Representational_State_Transfer has some details.