PUBLIC MARKS with tag restful

spire.io provides, as its foundation, a simple REST API. As such, the first thing you do is some discovery to get all the URLs you need to get started.

opa It creates a RESTful wiki server which supports the following methods: GET, POST, DELETE.

HAL is a simple, generic hypermedia type based on JSON and XML for use in RESTful APIs.

POST only becomes an issue when it is used in a situation for which some other method is ideally suited: e.g., retrieval of information that should be a representation of some resource (GET), complete replacement of a representation (PUT), or any of the other standardized methods that tell intermediaries something more valuable than “this may change something.”

Your APIs should do this. There should be a single endpoint for the resource, and all of the other actions you’d need to undertake should be able to be discovered by inspecting that resource.

Ces normes permettent aux utilisateurs des services RESTful de savoir toujours où ils mettent les pieds

explore an example REST application that uses the open-source protocol OAuth to address security issues.

When designing your hypermedia Web API, you don't always have to use a custom media-type to express your data and linking semantics. Instead you can use a well-known, registered media-type.

RESTful web services are one of our core design patterns. Fielding’s thesis identifies four major constraints that identify a RESTful architecture (statelessness, resource-orientation, uniform interface, hypermedia-driven application state). Many “RESTful” APIs only get 3 out of 4 of these; we’ve begun experimenting with using XHTML as a media type for our APIs, and this provides a lot of power in terms of scalability and loose coupling between client and server.

Update: Changed title and first paragraph to emphasize that the interface does not adhere strictly to the REST canon. See Oliver Charles’ detailed critique below.

This is a place for exploring aspects of implementing applications using the REST architectural style. This may include statements about existing frameworks and libraries, general discussions about the nature of the style and how it may be expressed and/or encouraged via a programming framework, etc.

in a typical enterprise app there are three options for layers that you might want to expose using a REST API. These are the infrastructure layer, the domain layer, and the application layer.

For all its goodness, REST sometimes feels like trying to fit a square peg in the proverbial round hole. Some interaction patterns just don’t lend themselves well to the REST approach. Here are a few examples, taken from the field of IT/Cloud management.

The idea of Grendel is to provide an internal (behind-the-firewall) REST-based web service to keep a user’s data encrypted and ensure its integrity when the user isn’t using it. Grendel uses OpenPGP to store data, with the user’s password encrypting an OpenPGP keyset. That model makes it easy for a web site to store data safely and only decrypt it when the user is logged into the site. Since only the user has their password, once they log out, their data is safe, even if the web site’s database is compromised or stolen. Of course this isn’t an infallible protection — there is no such thing — and in particular it doesn’t protect against web site developers acting in bad faith. It does, though, protect against an attacker getting access to all the secrets stored by users in one step.

Monarch is a set of libraries and tools for creating high-performance REST-based, native JSON Web Services. Monarch is best suited for sites that rely on thousands of AJAX calls per minute to provide their core functionality. For more information on Monarch performance, check out the blog posts at Digital Bazaar.

The suggested URI pattern is based on the distinction between non-information resources (abstract or concrete real-world objects), generic resources, and their representations. Generic resources are Web documents describing the abstract object they are associated with (e.g., a Dewey class). The pattern for generic documents defined in the current pool of Dewey URIs is as follows:

Recently InfoQ did a good summary of the debates around the apparent (to some) limitations of REST when it comes to creating good Web services. At issue is that REST APIs seem to expose "CRUDy" services that fly in the face of years of good services design, particularly when they are just read/write interfaces instead of the richer, full REST architecture (more on what this is later.) The discussion was spurred by Arnon Rotem-Gal-Oz's assertion recently that CRUD is bad for REST, which in my opinion is close but not quite right.

J'étais en train de lire RESTful Email over HTTP et ça m'a rappelé un vieux vaporware, je me demande s'il ne serait pas intéressant de regrouper toutes les notifications en un unique endroit. Il suffirait pour cela d'accepter plusieurs choses en entrées :

* emails (pull/push)

* flux (pull)

* jabber (push)

* webhooks (push)

* irc (bonus !)

Django may be the Python web framework getting all the press recently, but web.py is definitely a nice, simple framework. One of the nice aspects of web.py is that it exposes methods for the basic HTTP methods (GET, POST, PUT, DELETE, etc.) and uses these methods to process each request from the client. This approach makes it amazingly easy to write a RESTful API.

API designers, please note the following rules before calling your creation a REST API:

This is a design scratchpad for an HTTP RESTful API for Bugzilla. It will be implemented as a proxy, using a variety of methods (the existing API, web scraping) on the back end and with a clean interface as defined here on the front end.