I would like to create a module for the Pinboard API.
Though very similar to the old Delicious API, there are enough changes that I would like to re-implement to specifically work for Pinboard.
The Net::Delicious module was build initially in 2002 and I see that many of the newer REST best Modules are implemented in a new way. Net::Twitter, WebService::Dropbox and WWW::Vimeo::Simple seem to have different methodologies on how to implement their respective REST API.
Net::Twitter is very complex and heavy implementation in my opion. WebService::Dropbox is extremely light as is the API it implements. WWW::Vimeo::Simple seems to be between the two in terms of complexity.
I also spent some time looking at REST::Client but it probably would not be useful if you want to implement more that one or two methods.
What are the best practices for implementing a complete REST webservice? and also to test the responses without being able to connect to the service.
What you want is Net::HTTP::Spore. It's a moosy framework for REST clients in modern Perl. See also these slides
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 have been reading about the articles on the web about the benefits of graphql but so far I have not been able to find a single benefit of it.
One of the most common benefits mentioned in those articles are below?
No Overfetching with GraphQL.
Reducing number of calls made from client side.
Data Load Control Granularity
Evolve your API without versions.
Those above all makes sense but it is not the graphql itself that provides these benefits. Any second layer api written in java/python or any other language would be able to provide this benefits too. It is basically introducing another layer of abstraction above the data retrieval systems, rest or whatever, and decoupling the client side from that layer. After you do that everything you can do with graphql can also be done with any other language too.
Anyone can implement a say scala server that retrieves the data from various api's integrates them, create objects internally and feeds the client with only the relevant part of the data with total control on the data. This api can be easily versioned and released accordingly. Considering the syntax of graphql and how cumbersome it is and difficulty of creating a good cache around it, I can't see why would you use it really.
So the overall question is there any benefits of graphql that is provided to the application because of the graphql itself and not because you implement another layer of abstraction between your applications and your api's?
Best practices known as REST existed earlier, too.
GraphQL is more standarized than REST, safer (no injections) and syntax gives great flexibility in the area of quickly changing client needs.
It's just a good standard of best practices.
I feel GrapgQL is another example of overengineering. I would say "Best standards and practices" are "Keeping It Simple."
Breaking down and object and building a custom one before sending it to the client is very basic.
If I develop Booking REST service in Golang (i.e., in package booking). Is it a "GO way" to create BookingClient interface (backed up by struct) with business operations allowed, so that clients of my restful service would use BookingClient (imported from package booking) instead of sending http requests directly?
In general, no – if you provide a client in a particular language it'd only be a convenience, so (some) users can use your API easier. This of course assumes your client is well designed. I wouldn't provide merely an interface in Go just to indicate a set of possible API calls. This would be beneficial to a very narrow range of audience, probably for people developing a client for your API themselves, in programming language which just happened to be the same as implementation of your server. And even then they might not really like the idea of using the interface (e.g. they might only need a specific set of methods).
If you want to provide a client for your API, go ahead, do it, but separate it from the actual server (different package, maybe even different repo). In general one develops APIs over HTTP to allow for wide range of clients to access it, which could be written in any language. Instead of providing some interfaces I would invest my time in writing a good documentation.
In my opinion the answer to your question, assuming there is no more context provided, should be no different if you asked yourself if you should provide a client in, say, Python. The whole situation might change though if, for example, your API is used internally by your company and you develop mainly in Go.
It's usually preferable to do this, and most companies do, but provide documentation for working directly with the API. The main use case for that is people working with different languages than the ones you intended.
You can have a look at a new RESTful framework I wrote, that includes infrastructure to automatically compile clients with Go templates, although I haven't gotten to writing a Go client compiler. If you want to write one it would be greatly appreciated :) https://github.com/EverythingMe/vertex
Testing is important in Go, so writing testable code is something you should do. If you use direct http requests you will have a harder time writing unit tests, compared to using a mocked struct.
Is there any reason to use a Client rather than calling the functions that call the REST endpoints? It's usually harder to mock a bigger thing, such as a Client struct, rather than a group of small functions.
You should put the client at booking.Client to avoid repeating yourself (booking.BookingClient) and maybe rename Client to something more descriptive.
they're exposing a REST and SOAP API to access data but none of them seems really fitted to my purpose of inserting lots of data through external RPC calls, which are somehow time-critical (There are a dozen users working the same time on the data).
I only spend a few hours to get an idea how things work in SugarCRM but I figured out its best to place an independent RPC server beside of SugarCRM and then do the processing(huge) part and afterwards storing it into the database, using preferable Sugars own API.
Is there a way to include their core API in order to benefit from their model and persistence API ?
I'd like to know which files I need to include and how to access the running instance, if there is one.
Its actually quite simple what I am trying to do :
Receiving RPC calls
Do some matching
Update database
You see, there is no GUI part involved which justifies the long way of using modules, etc..
Well, I hope someone knows it. Its seems a pretty big beast to me and I'd love to keep it quick'n dirty.
thanks !
Here You find a starting point for your own API Extending the REST API and here is a overview of what API versions exist.
We are using a time critical custom API to speed up some calls.
For a college project i'm thinking of implementing the business layer in Erlang and then accessing it via multiple front-ends using REST. I would like to avail of OTP features like distributed applications, etc.
My question is how do I expose gen_server calls/casts to other applications? Obviously I could make RPC calls via language specific "bridges" like OTP.net or JInterface, but I want a consistent way to access it like REST.
As already mentioned Yaws or Mochiweb are a great way to go but if you'd like a dead simple way to get your RESTful API done quickly and correctly then use Webmachine. It's a layer on top of Mochiweb that implements proper HTTP behavior based on Alan Dean's amazing HTTP flow diagram and makes it easy to get REST done right.
I'm using it right now to expose a REST API as well as handle a COMET application and it's been pretty easy to do, even for an Erlang newbie such as myself.
I did something similar for my job and found it best to use REST to expose the business layer because even Legacy languages such as SoftwareAG's Natural is able to access it. The best mechanism that I have found in Erlang is to use Mochiweb.
You can find more information about using it from the screencast located at
Erlang In Practice Screencast. Episode 6 is particularly helpful but all of them are excellent.
A resource to walk you through installation is How To Quickly Set Up Ubuntu 8.04 loaded with Erlang, Mochiweb and Nginx and Migrating a native Erlang interface to RESTful Mochiweb (with a bit of TDD) provides a good start if you don't find the screencasts to your liking.
The HTTP flow diagram link is dead. The original version and a updated version created in collaboration between Alan Dean and Justin Sheehy ist also hosted in the Webmachine project: link to latest version of the HTTP Diagramm.
There is valuable approach to design gen_server calls/casts in flavor of REST if possible. You can use messages as
{get, Resource}
{set, Resource, Value} % aka PUT
{delete, Resource}
{add, Resource, Value} % aka POST (possible another names are append, modify or similar)
Then its mapping is easy. You can make some transformation URI->RESOURCE or use identity. For most of your application this should be wort approach and special cases you should handle specially. You can think there will be big margin, where you can't use this approach, but this should be mostly premature optimization.
Do you really mean a RESTful interface or RPC over HTTP? Building a RESTful interface on top of an existing layer is more work than just exposing existing methods via HTTP.
I'd suggest to use mochiweb or yaws to implement a (generic) rpc layer.
Just an update, Webmachine has moved to bitbucket: new link to Webmachine