Eve: Python REST API Framework

Powered by Flask, MongoDB, Redis and good intentions Eve allows to effortlessly build and deploy highly customizable, fully featured RESTful Web Services
Check out the Eve homepage

• GitHub

Eve is an out-of-the-box, highly customizable and fully featured RESTful Web API framework that you can use to effortlessly build and deploy your own APIs

Eve is Simple

from eve import Eve

app = Eve()
app.run()

The API is now live, ready to be consumed:

$ curl -i http://example.com/people/
HTTP/1.1 200 OK

All you need to bring your API online is a database, a configuration file (defaults to settings.py) and a launch script. Overall, you will find that configuring and fine-tuning your API is a very simple process.

Eve is thoroughly tested under Python 2.6, Python 2.7 and Python 3.3.

Features

• Emphasis on REST
• Full range of CRUD operations
• Customizable resource endpoints
• Customizable, multiple item endpoints
• Filtering and Sorting
• Pagination
• HATEOAS
• JSON and XML Rendering
• Conditional Requests
• Data Integrity and Concurrency Control
• Multiple Insertions
• Data Validation
• Extensible Data Validation
• Resource-level Cache Control
• Versioning
• CORS Cross-Origin Resource Sharing
• Read-only by default
• Default Values
• Predefined Database Filters
• Projections
• Event Hooks
• Native MongoDB Support
• SQL Alchemy Support (WIP)
• Powered by Flask

Why REST is so important

http://babdev.blogspot.co.at/2013/07/why-rest-is-so-important.html

This post is dedicated to REST, an architectural style of shaping webservices and the most misunderstood concept in the history of IT. This post is addressed to you who is designing webservice apis not being fully aware what REST actually means.

The meaning of REST

Why RPC is a pain in the A**

But SOAP is still bad

Sessions are Evil

Dont reinvent Hypermedia

Further Resources

In this post, i have only scratched the surface of the advantages of REST. 
Here are some good resources to get you a deeper understanding.

• Fowlers Article on the Richardson Maturity Model
• A great slide on Hypermedia
• A talk by David Zuelke on RESTful Webservices
• Intro to REST (short video of GoogleDevelopers)
• A talk of Lez Hazlewood (Stormpath)
• A Cookbook for RESTful WebServices
• Great German Book about REST

Posted by Gregor Riegler 

http://babdev.blogspot.co.at/2013/07/why-rest-is-so-important.html

An Overview of REST Metadata Formats

Although the REST community initially took a stance against metadata for REST APIs, a number of metadata standards have none-the-less emerged over the last couple of years, mainly fueled by the need to document APIs for their consumers.

...

The common goal of current metadata formats for REST APIs is to specify

• Entry point(s)
• Resource paths
• Methods to access these resources (GET, POST, PUT, etc.…)
• Parameters that need to be supplied with these methods (Query, Template, HTTP Header, etc.)
• Formats of inbound / outbound messages/representations (JSON Schema, XML Schema, Relax NG, etc.)
• Status codes and error/fault messages
• Documentary information (descriptions, etc.) for all these

All these are somewhat derived from the principles underlying REST APIs – i.e. those of resources, representations etc. Non-functional aspects of APIs, like for example authentication (Basic, OAuth, SAML, etc.), security (encryption, signatures, etc.) and versioning are unfortunately still poorly addressed by most REST metadata standards. This is where the WS-* standards “shine”, but it is also what many refer to as WS-(death-star) – indicating the complexity of the WS standards that might ultimately lead to their demise. Hopefully the REST community will align around common standards and best practices more successfully than vendors did in the SOAP-domain around 10 years ago.

...

From: http://apiux.com/2013/04/09/rest-metadata-formats/

Secure Your REST API... The Right Way

Secure Your REST API... The Right Way:

At Stormpath we spent 18 months researching best practices, implementing them in the Stormpath API, and figuring out what works. Here’s our playbook on how to secure a REST API.

Brian Sletten on RESTful API Design

Brian Sletten on RESTful API Design:

Brian Sletten, the author of the DZone REST Refcard dispels pre-conceived notions about REST API design while going over Representation Design, Versioning, and more...

Designing a Beautiful REST+JSON API

Designing a Beautiful REST+JSON API:

In this presentation, Les Hazlewood - Stormpath CTO and Apache Shiro PMC Chair - will share all of the golden nuggets learned while designing, implementing and supporting JSON-based REST APIs, using examples from a clean real-world REST+JSON API built with Java technologies.

What Legos Teaches Us About REST API Testing

What Legos Teaches Us About REST API Testing:

Learn about REST API Testing Patterns

Thoughts on RESTful API Design

Thoughts on RESTful API Design by Geert Jansen

This essay is an attempt to put down my thoughts on how to design a real-world yet beautiful RESTful API. It draws from the experience I have gained being involved in the design of theRESTful API for Red Hat’s Enterprise Virtualization product, twice. During the design phase of the API we had to solve many of the real-world problems described above, but we weren’t willing to add non-RESTful or “RPC-like” interfaces to our API too easily.

In my definition, a real-world RESTful API is an API that provides answers to questions that you won’t find in introductory texts, but that inevitably surface in the real world, such as whether or not resources should be described formally, how to create useful and automatic command-line interfaces, how to do polling, asynchronous and other non-standard types of requests, and how to deal with operations that have no good RESTful mapping.

A beautiful RESTful API on the other hand is one that does not deviate from the principles of RESTful architecture style too easily. One important design element for example that is not always addressed is the possibility for complete auto-discovery by the API user, so that the API can be used by a human with a web browser, without any reference to external documentation. I will discuss this issue in detail in Forms.

Author: Geert Jansen <gjansen@redhat.com>

https://github.com/geertj/restful-api-design

J2EE: Compare RESTful vs SOAP Web Services

J2EE: Compare RESTful vs SOAP Web Services:

There are currently two schools of thought in developing Web Services – one being the standards-based traditional approach [ SOAP ] and the other, simpler school of thought [ REST ]. A simple comparison grid is below.

What Makes a Great API? The Five Keys

Source: http://blog.programmableweb.com/2012/07/19/what-makes-a-great-api-the-five-keys/

5 Keys to a Great API

• Provide a valuable service
• Have a plan and a business model
• Make it simple and flexible
• It should be managed and measured
• Provide great developer support

What Makes a Great Open API? from jmusser

Top 10 API Worst Practices (Restful API)

Source: http://blog.programmableweb.com/2012/08/03/top-10-api-worst-practices/

• Poor error handling
• REST APIs that ignore HTTP rules
• Exposing your raw underlying data model
• Security complexity
• Unexpected and undocumented releases
• Poor developer experience
• Expect an MVC framework “gives” you a great API
• Assume if you build it they will come
• Inadequate support
• Poor documentation

Many of these issues came up in the developer survey that said Facebook causes the most developer pain.

Open API with Restlet

Open API with Restlet:

This talk introduces in detail how to develop a RESTful web API in Java thanks to Reslet Framework, the first open source project to offer a REST toolkit in 2005.

Learn REST: A Tutorial

http://rest.elkstein.org/2008/02/what-is-rest.html

1. What is REST?

REST stands for Representational State Transfer. (It is sometimes spelled "ReST".) It relies on a stateless, client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used.

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

• In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture.

RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.

REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.). Later, we will see how much more simple REST is.

• Despite being simple, REST is fully-featured; there's basically nothing you can do in Web Services that can't be done with a RESTful architecture.

REST is not a "standard". There will never be a W3C recommendataion for REST, for example. And while there are REST programming frameworks, working with REST is so simple that you can often "roll your own" with standard library features in languages like Perl, Java, or C#.

Designing Hypermedia APIs

Designing Hypermedia APIs:

Ruby on Rails did a lot to bring REST to developers, but its conception leaves the REST devotee feeling a bit empty. "Where's the hypermedia?" she says. "REST isn't RPC," he may cry. In this talk, Steve will explain how to design your APIs so that they truly embrace the web and HTTP. Pros and cons of this approach will be discussed, as well as why many aren't building things this way yet.

Laravel 4: A Start at a RESTful API

Laravel 4: A Start at a RESTful API:

RESTful API's are hard! There are a lot of aspects to designing and writing a successful one. For instance, some of the topics that you may find yourself handling include authentication, hypermedia, versioning, rate limits, and content negotiation. Rather than tackling all of these concepts, however, let's instead focus on the basics of REST. We'll make some JSON endpoints behind a basic authentication system, and learn a few Laravel 4 tricks in the process.

Going REST/NoXML: Embedding Jetty with Spring and JAX-RS using Apache CXF

Going REST/NoXML: Embedding Jetty with Spring and JAX-RS using Apache CXF:

For hardcore server-side Java developers, the only way to "speak" out to the world is by using APIs. Today's post is all about JAX-RS: writing and exposing RESTful services using Java.

Streaming APIs: JSON vs XML and REST is King

Streaming APIs: JSON vs XML and REST is King:

Streaming APIs are becoming more popular because of the low latency they provide. What are the common protocols and data formats of these APIs? To find out I did a simple search on APIhub, the largest repository I found for streaming APIs. Here were the results of the 104 APIs that came up… (I cut out a few of the very low-count protocols and data formats):

Web Services Are Dead -- Long Live REST

Web Services Are Dead -- Long Live REST:

Once, an endless parade of Web service protocols promised to guarantee any system could talk to any other. In the end, we got much of that interoperability via simpler means.

Why HATEOAS is not the witch to burn

Why HATEOAS is not the witch to burn:

But HATEOAS is a model that allows you to allocate to the server some of the responsibilities of your API's use cases: which are the next steps, where they are executed, whether to skip any, or to perform further redirections. HATEOAS isn't a reminescence of WS-* as much as slapping the REST label over remote procedure calls is a reminescence of RMI and CORBA (too many acronyms today!)

From database to RESTful web service to HTML5 in 10 minutes

From database to RESTful web service to HTML5 in 10 minutes:

Using NetBeans IDE 7.3, guest author and NetBeans team member Geertjan Wielenga shows us how to expose data from a database via a JAX-WS RESTful web service and how to consume the service in an HTML5 application, via a range of tools for working with HTML5, JavaScript, and CSS. All in 10 minutes.

How NOT to Design Your API.

How NOT to Design Your API.:

Recently I tweeted as a #linktuesday link the 10 Worst API Practices post from ProgrammableWeb. Today, in search of some concrete examples of APIs implementing unhelpful antipatterns, I sent out a tweet for help:

Writing REST services with JAX-RS and Spring

Writing REST services with JAX-RS and Spring:

A framework for quickly writing and deploying REST services in java. Using JAX-RS, Spring Data, Spring Integration, Hibernate.

RESTful SAML?

RESTful SAML?:

Existing brokered authentication standards such as SAML Web Browser SSO or OpenID accommodate RESTful web services for browser driven use cases. However, what about RESTful service composition patterns where identities need to be propagated across nested service invocations, or any RESTful Web service client that is not browser based for that matter? How should brokered authentication for such RESTful service calls be handled?

Securing RESTful Web Services with OAuth 2.0

Securing RESTful Web Services with OAuth 2.0:

One of the questions we get asked the most by developers and architects is: when and why would I use OAuth2? The answer, as often with such questions, is "it depends", but there are some features of OAuth2 that make it compelling in some situations, especially in systems composed of many lightweight web services, which becoming a very common architectural pattern.

How to Protect Your APIs with OAuth

How to Protect Your APIs with OAuth:

We tackle an increasingly important question in the world of APIs: Presume that you would like to create a remote API (which perhaps exposes some API is protected in such a way that: A) Only clients that you trust can access them; B) Those clients can access your API through the explicit authorization of their end-users; and C) The end-users can be authenticated with a central entity, *withouth* having to share their credentials with your API’s clients.