Im looking to mock out calls to a third party API from my scala microservice. Can anybody recommend a library they have tried and tested for this? I have seen a couple of older and not very active projects on github, but they do not look too promising.
This mock server is appropriate for your purpose, like alternative, you can look at [simplle framework][2], which is very simple in use, btw, they provide examples of usage.
I used wiremock (Java)
It's very simple and yet powerful.
Related
One of the key points of building a RESTful API is HATEOAS. Now, Jersey offers a linking ability which is quite good (see this link). But I have seen the draft of the HAL Specification and it seems to be a well thought piece of work.
I am interested if there is some lib that makes it easy to adhere to HAL in Jersey. I have seen the references mentioned in the draft like https://github.com/HalBuilder. But I am using direct POJO marshalling and I do not know how to mix that with Halbuilder.
So, is there already some lib that incorporates HAL into Jersey? Or maybe I can use some kind of filter to enhance the generated POJOs manually? If yes, can someone give me a clue where to look next to accomplish this?
I can't find any direct support for this in Jersey, but there should be ways to customize the marshaller that Jersey uses to convert your POJO's to JSON. (either by using HalBuilder, or create some HAL-compatible code of your own)
If you use Jerseys JAXB based JSON support, take a look at BootstrapTypeConverterTest in the jettison source code which demonstrates how a converter can be used to cusomize JSON output. Unit-testing conversions to/from JSON should be a simple task and jettison-project has good examples to look at.
If you use Jerseys "POJO Support"-method, take a look at JacksonHowToCustomSerializers for a similar example on how to create your custom serializers.
(If JAXB is involved, you can also do cool things like processing custom annotations.)
You probably have a pretty good idea of how your objects (input) looks like and what JSON code (output) you expect, so creating unit tests for these conversions should be a relatively simple task.
Even if this is not really an answer, I had not enough characters to put it in a comment :)
If you're really new to REST, I think you're beginning probably in the wrong way. I don't know exactly your requirements, but if you only want to learn, begin with an easy REST service, use Web API from .net or something similar in Java (a simple servlet would be enough) and try to implement a service which only uses the tools delivered by http (the verbs, the request header and payload, the response message). REST API design rulebook from Marc Massé could be a good reference to learn. Create your own communication protocol with POJOs or POCOs and once you really what you can do REST and how it works, you can use a framework to ease your work.
If you begin with a framework you may miss the essence of the concept...
I hope it helps!
It's very little that's required to adhere to HAL. I suggest you roll your own mini-library where you wrap your POJOs in HAL-objects. This way you get the code the way you like it and it will be way simpler than HalBuilder.
I've not looked into BackboneJS or EmberJS in detail, but as I understand, it is possible to have BackboneJS seamlessly work with a REST back-end. Whereas EmberJS doesn't seem to have anything I can use out of the box.
Can anyone offer any advice how to achieve this with EmberJS?
If you just need a simple REST adapter without much complexity, then
https://github.com/cerebris/ember-rest
is great for the job.
I've written an article about Ember.js on InfoQ, that goes through the basics. The article used Ember 0.9.5, so not everything will be working with the newest Ember 1.0-pre release.
It goes through the basic structure of an Ember-app as well as the very basics with Ember Data.
http://www.infoq.com/articles/emberjs
I think you're looking for something like Ember-rails
https://github.com/emberjs/ember-rails
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
Striving to ship a well documented application, I'm looking for a good way to describe a REST API for my Grails Application users.
I know that REST calls should be simple enough to be described by examples, but it doesn't feel formal enough.
I've spent a couple of hours looking for a solution suggested by other Grails users, but didn't find a neat solution besides a recommendation to use WADL or WSDL 2.0
This looks like a good direction, but there must be a simple way to do it in Grails.
I'd appreciate some guidance for a process to generate a REST API based on my model objects preferably with the ability to filter or control the exposed fields, plus, a nice graphical way to present it (something like the XSD Eclipse plugin)
Thanks!
Guy
I would suggest to avoid WADL or WSDL for API documentation, you can see this question where I explained my reasons: Why the slow WADL uptake.
WADL or WSDL are usually used for automatic client code generation, they are not human readable documentation. I don't think WADL or WSDL are very useful for a user to figure out how to consume the resources correctly.
I prefer the good old html documentation, for example I like the way twitter documented their API
If you insist on automatic generation of resources documentation I can recommend on the ATOM service document. Many REST framework can generate it automatically based on the resources annotations. (e.g. Apache Wink)
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