Does anybody know a wiki engine that can be built on top of a RESTful application?
I have a restful application, that exposes a document resource,
I want the wiki engine to use the REST API to persist the documents, instead of saving them to a DB.
I am also open for suggestions of an open-source wiki engines that can be easily modified to support such functionality.
As Wikis were originally designed to work in a standard browser, and most browsers did not support anything except GET and POST, REST is not a concept used a lot on the wiki world. However, nowadays, some wikis (foswiki - the community fork of TWiki for instance) provide you a REST API to it http://foswiki.org/System/CommandAndCGIScripts#rest ).
But you need the opposite: a wiki with a customizable backend (storage) that could be plugged on top of a REST storage service. As wikis with a pluggable backend, I know only of pmwiki http://www.pmwiki.org/wiki/PmWiki/PmWiki and foswiki (the open fork of TWiki) http://foswiki.org.
Okay, this is a puzzler. Wikis in general are more or less the canonical example of a RESTful approach. The page name names a resource. What do you want that isn't in, eg, Twiki?
While you could try to find a wiki that can use a REST backend, it may be better to write a small wiki yourself. Because even though a your backend has REST interface, that doesn't mean you can put some other application in front of it.
dokuwiki does not use a database. It is a filesystem based wiki. I don't know its internal code structure but you might be able to use it as your base.
Related
I have a single page app built with emberjs with an a rails backend. Is it a common pattern to build an admin interface on rails serverside on a subdomain. What is the right approach for this?
Your question is vague but I will try to answer it my best. I have done this with a Node and a Go backend combined with Ember.js.
No, there is technically nothing to prevent you from doing a single page application for an admin interface.
Rails is a good choice for this, and generally you should stick with the backend framework/language you and your team master the most.
As for what would be the right approach, there is no magic recipes. Document your code, write test and follow best practices for the tools you are using.
One key element though will be the communication between your frontend and your backend. Ember chose to follow the JSON API specification (http://jsonapi.org/) and comes out of the box with an adapter to talk with these kind of API. Using such adapter will help you save a lot of time.
Here are some implementation of JSON API for Ruby : http://jsonapi.org/implementations/#server-libraries-ruby
One more thing about your frontend code structure. You haven't say how big your app will be. If it gets big, you may want to take the pod approach in ember-cli (http://ember-cli.com/user-guide/#pod-structure). It basically changes the structure of the code so it's easier to maintain a lot of files.
may I have some example/typical use case of HATEOAS? I agree it can be a very powerful concept provide great flexibility but I am not sure how to properly get benefit from HATEOAS. would be great if you can share your experience/use case.
A good answer from #dreamer above, but HATEOAS is not present in most REST-based services. It is a constraint on the REST architecture style that allows clients to interact with a service entirely via the hypermedia contained in the resources.
If you look at the Twitter or Facebook REST APIs, you won't find hypermedia. Look at the Facebook friendlist resource. There are no hypertext links in that resource that you can use to transition the state of the resource - to delete, update, etc. Instead, you need to read the out-of-band documentation to understand what you need to do to delete that resource.
One of the claimed advantages of using hypermedia in your APIs is that you can manage change within the resources themselves. For example, what if Facebook wanted to add additional functionality to the frendlist? If it were built with HATEOAS in mind, the resource would be updated to add the hyperlinks provides those additional state transitions.
If this sounds difficult, you're right. But as a developer of client applications, however, once you understand how the hypermedia is presented, you can build applications that will evolve along with the API itself.
So how do you build APIs using HATEOAS? A number of options are out there, but I like the Hypertext Application Language (HAL) the best.
UPDATE: Since you asked for an example, here's a link to a demo using HAL.
Good public HATEOAS use cases are hard to find, because there are a lot of misconceptions around REST, and HATEOAS can be hard to implement. You really need to have a good understanding of its benefits, before you're willing to put yourself through the trouble of getting it to work, and if the clients don't follow it correctly, all work will be in vain.
From my experience, implementing proper REST in a company is a culture change as important as moving to version control systems or agile development. Unless everyone adopts it and understands it, it causes more trouble than it solves.
Having that in mind, I think the best example one will find is the foxycart.com HAL API, on the link below:
https://api-sandbox.foxycart.com/hal-browser/hal_browser.html#/
It's very powerful concept used in RESTful presentation of the application to the client. There are many many projects which are adopting this interface now. A typical use case for this is Web Services APIs using RESTful APIs. A RESTful APIs typically consists of the following elements:
base URI, such as http://example.com/resources/
an Internet media type for the data. This is often JSON but can be any other valid Internet media type (e.g. XML, Atom, microformats, images, etc.)
standard HTTP methods (e.g., GET, PUT, POST, or DELETE)
hypertext links to reference state
hypertext links to reference related resources
The application state can be modified using above HTTP methods for example, to get a particular resource, A client can issue a REST query using curl like:
curl -X GET --url "http://example.com/resource/" -X "Content-Type:application/json"
you could go through the man pages for curl and its usage. More on RESTful interface concepts can be looked upon at wiki
I'm currently developing a web application, that relies heavily on mobile and desktop clients consulting the web server for information. This can be accomplished nicely making a RESTful API available to handle this. So my idea is to have an application acting as the "platform" which handles all the real business logic and database information behind the curtains.
My plan is to make the platform using symfony2 and OAuth 2.0 authentication mechanisms, combined with RESTful web services.
Now my real dilema comes on the website component. Ideally I would like to think of the website as yet another client that asks this REST platform for information, and completely separate it from the platform itself.
To make it a little bit more clear, let's say we are making a blog with this architecture, so one would have a "platform/backend" that provides a rest service to list articles, for example: /articles/5. This on the backend, and with symfony2/doctrine means that the app has an Article model class, and these can be requested from the DB. A simple controller queries for the Article number 5 and returns all the information in JSON format.
Now the website on this example, could just do the easy thing and also have an Article entity and just query the database directly, but I think it would be cleaner if it could just talk to the platform through it's REST api and use that information as a "backend" for the entities.
So the real question would be, is there anyway to support this kind of design using symfony2? Have entities rely on a REST api for CRUD operations? Or I'm just better off making the platform/website a single thing and share a "CoreBundle" with all the generic entities?
There is nothing in Symfony that prevents you from doing you want.
On the client side you could use Backbone.js or Spine.js.
Have a look at FosRestBundle, it makes your life much easier to create api:
https://github.com/FriendsOfSymfony/FOSRestBundle/blob/master/Resources/doc/index.md
We're looking for a general RESTful API solution for our Django project. We would use the API at first for Ajax calls on the web site and later for mobile apps, external apps and things like that.
I found two modules which seem to be widely used. django-piston and django-tastypie
From what I read, piston seems to be older and thus more mature but maybe a bit outdated?!
While tastypie is relatively new and nicely documented.
What would be the best thing to go with? django-piston or django-tastypie?
Important for us (ordered by priority): Continuous maintenance of the source, documentation, stability, ease of use.
EDIT (2013 Jul 16th):
Now over a year later we have a clear winner. At first we went with tastypie. Which we kinda liked. But after half a year or so we switched to the then upcoming django-rest-framework and never looked back.
What we like most about it:
Nice documentation
Active community
Clean design (build upon django's class based views)
Browsable API for development and debugging
We rely on the API heavily so support (in the future) is one of our main concerns. We met the maintainer - Tom Christie - (on and offline) and he seems very committed to the project. So we feel very comfortable using the django-rest-framework.
A good resource to compare them is http://www.djangopackages.com/grids/g/api/
Django-tastypie sure is the save choice right now.
Personally I'd advocate a look at django-rest-framework if you use django 1.3, because it uses the new class based views. djangopackages.com's comparison page shows it has good participation and activity. And, wow, it sure has a nice browsable interface to the API.
I have no experience with this, but I trust Pydanny in this:
django-piston has been barely supported for nearly two years. That is
an eternity, and the number of forks to address multiple issues is a
cause for alarm. Because of that, in it's place at this time I
recommend django-tastypie. It is up-to-date, has very good
documentation, supports OAUTH, and scored second place in the Django
Packages thunderdome (it got nearly 3x as many points!). Another tool
to consider is Django Rest Framework, which is as good as
django-tastypie but lacks the OAUTH support.
On the django-piston front, Joshua Ginsberg has taken over the reins
and we should hopefully see some movement again. In which case I'll be
able to remove this section of the blog post.
from Pydanny's blog.
Having implemented API's with django Piston, tastypie and django webmachine Django tastypie rocks! Having said that, I think that while tastypie is really good when your API is modelled close to your models, it's a little bit more complicated to do things once you want to move out of the box. There are workarounds to some issues, with others you have to do more bending than building. It will, probably, still cover 90% of django use cases.
Afaik Webmachine was modelled after the popular erlang webmachine, but hasn't been very active lately. So that leaves piston, which is picking up some activity, and tastypie, that has a lot of momentum and activity. Piston is a bit more flexible, but tastypie is moving very fast and in my opinion has a really easy API.
My recommendation would be to quicky implement a prototype of the API in tastypie, and see if it covers what you want to do.
Django REST framework 2.0 was anounced in Oct 2012 and now supports OAuth out of the box. What I really like is the Web browseable API, which is really helpful when developing your API, but also when someone implements your API. It's kind of comparable with using the Django admin site for inspecting your models' structure and data, but then for your API. Also the documentation is very good.
From their website:
Django REST framework is a powerful and flexible toolkit that makes it
easy to build Web APIs.
Some reasons you might want to use REST framework:
The Web browseable API is a huge usability win for your developers.
Authentication policies including OAuth1a and OAuth2 out of the box.
Serialization that supports both ORM and non-ORM data sources.
Customizable all the way down - just use regular function-based views if you don't need the more powerful features.
Extensive documentation, and great community support.
Check out their Quickstart guide to get a quick idea of how it works.
I thought to practice SOAP API. I know it is a time for REST but I thought to give a try to SOAP. I somehow got Flickr.com API supporting SOAP but it has very difficult documentation. No, working examples are available.
Q1. So, do anyone know where I can learn SOAP. Do anyone has SOAP working example for Flickr API
Q2. Any service other than Flickr providing SOAP interface. I saw Google search api has closed new request for SOAP.
regards
SOAP has been largely superseded by REST on the public Internet - as you have noted in your question and has been alluded to in comments.
There are still large users in the Intranet context, companies with an installed base of SOAP, Service Bus, and other concepts that you may well come across if you end up working at one of them. (There are still CORBA users out there also!) When you control both ends of the application, you may have less reason to be flexible using REST.
So if you are looking for useful public implementations you are mostly out of luck.
That said: do create your own services and try them out on your own. Define a service and implement it. Create a client in a different language. Create another client in a third language.
If you are looking for an educational experience, this will lead you down some of the same paths that has lead to REST use in wide-scale disparate systems (and may also shed light on why the public/private has split the way it has)
Good Luck