When I hear API, I think the only way to use an API is to write a program to call the functions provided by the API.
Is writing a program the only way of using a RESTful API?
It seems that we can use curl to use RESTful API in https://developer.github.com/v3/guides/getting-started/. So how is that possible without writing a program to call the functions provided by a RESTful API?
Thanks.
There's no reason you can't invoke a RESTful API via a utility such as curl.
However, it only works for the simplest of use cases.
Most use cases have several steps that simply work better through automation. From creating or interpreting the payloads that are sent/received from the API calls, to orchestrating several calls in a larger transaction.
Also, consider, if you put your curl command in to a script file, then, well, that's "programming".
Related
I am quite new to JGiven and currently I have a set of REST API tests automated using Rest Assured and TestNG framework. I am also exploring JGiven as a framework to run the API tests for the advantages it gives with the human readable given when thens and the reports that it generates too. Rest Assured as a library lets us inject the URLs and actually make the REST calls. I want to understand if we have such capabilities within JGiven to actually make the REST calls. If so, I'd like to see an example and understand how I can do that. If not, can someone kindly advice and suggest the best way to achieve it with JGiven. I've been trying to search for this information but have struggled to do so thus far.
Thanks in advance.
JGiven is useful for creating test scenarios that are understandable by domain experts. It is a general tool that can be used for any kind of testing, including testing REST APIs. JGiven adds an understandable layer on top of your underlying test infrastructure. However, you will typically need tools in addition to JGiven to implement the underlying layer. So for testing REST APIs you will use a tool like Rest Assured in combination with JGiven. With JGiven you describe your scenario in the domain language, with Rest Assured you will execute the REST calls.
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 want to know is there any tool/product/library to call rest api and process its output, add some conditional logic to further call another rest api call. Something similar to yahoo pipes.
The tool should have a UI to configure all these instead of writing a program.
I think you are looking for Postman.
Link: https://www.getpostman.com/
I am currently in the throes of writing a plugin for Bugzilla, and so all of the code needs to be written in Perl. I have everything working quite nicely, however there are a few places where I know I need to do multiple requests to the same REST server, and, given that it might be distant network wise, I would like to be able to send several requests, and then wait for them all to come back, rather than do the Stop-And-Wait Send/Wait/Send/Wait.
Using REST::Client allows for very easy access to REST client functionality, which is what I am currently using. The top Google result for perl sync rest is HTTP::Async, but this page doesn't address REST directly, and it is not clear to be how to easily use HTTP::Request to easily process them.
What is the best way to do this?
Mojo::UserAgent is a very nice web agent that does async well.
Have anyone used REST in CF10 for production?
How is that better then ajax calling remote method, e.g. foo.cfc?method=blah?
Can you get your RESTful API pure stateless? Do you still rely on session cookie?
REST and remote calls to a method are two entirely different options, neither of which are necessarily "better". REST services in CF are stateless by default. It's really up to you if you want to get sessions involved or any other state for that matter. I would suggest reading more about REST to see if it's the kind of API you'd like to build. Good luck!