'REST' in Dev Breakthroughs

Tags
Current selected tag: 'REST'. Clear

Your new post is loading...

Scooped by Nicolas Weil

Scoop.it!

RESTful Standard Resolved!

From java.dzone.com - September 21, 2012 6:33 AM

Lately I'm trying to build a web application which will be exposed in a RESTfull manner.
There are some general guideline and hints about how to define it, but no explicit standard or accepted schema structure to use.

After reading some info on the web, I think I manage to crack the pattern :-)
I would like to share the rules and structure I formed and hopefully to get some feedback about it and improve it, so please don't hesitate to leave notes and point any pain point that structure has.

The high level pattern is:
http(s)://server.com/app-name/{version}/{domain}/{rest-convention}

more...

No comment yet.

Scooped by Nicolas Weil

Scoop.it!

Combining HTML Hypermedia APIs and Adaptive Web Design

From www.jayway.com - August 2, 2012 12:19 PM

HTML is the lowest common denominator in a world were the number of devices are steadily growing. In such a world, our API should be hypermedia driven and we should consider choosing HTML as the media type for our APIs. If we choose this, we can enhance the API with CSS and JavaScript, making the API human-friendly as well. Further, we can use Adaptive Web Design to make the best possible experience for all types of browsers and devices.

This kind of solution has some risks and technical issues related to it though. And it is not a silver bullet.

more...

No comment yet.

Scooped by Nicolas Weil

Scoop.it!

Edge Rails: PATCH is the new primary HTTP method for updates

From weblog.rubyonrails.org - February 29, 2012 6:48 AM

The HTTP method PUT means resource creation or replacement at some given URL.

Think files, for example. If you upload a file to S3 at some URL, you want either to create the file at that URL or replace an existing file if there's one. That is PUT.

Now let's say a web application has an Invoice model with a paid flag that indicates whether the invoice has been paid. How do you set that flag in a RESTful way? Submitting paid=1 via PUT to /invoices/:id does not conform to HTTP semantics, because such request would not be sending a complete representation of the invoice for replacement.

With the constraints of the methods GET, POST, PUT, DELETE, the traditional answer is to define the paid flag of a given invoice to be a resource by itself. So, you define a route to be able to PUT paid=1 to /invoices/:id/paid. You have to do that because PUT does not allow partial updates to a resource.

more...

No comment yet.

Scooped by Nicolas Weil

Scoop.it!

Short List of RESTful API Frameworks for PHP

From blog.programmableweb.com - September 23, 2011 8:41 AM

Having a web API is an essential part of doing business online today. We wanted to help get you started. So we took some time to pull together a list of the RESTful or RESTish (however you choose to view it) API frameworks, that can help you deploy your API faster.Today we are going to take a look at seven RESTful API frameworks for PHP:

- Dave

- Epiphany

- FRAPI

- Recess

- Slim

- Tonic

- Zend Framework

more...

David's comment, June 1, 2013 8:46 AM

The list is a bit out of date and some frameworks have hit a dead-end. For those evaluating frameworks herewith a quick list:

http://davss.com/tech/php-rest-api-frameworks/

It's best to evaluate by going to each API developers website and try to match your project needs to available features. Some frameworks have built-in others extend via modules.

Scooped by Nicolas Weil

Scoop.it!

OAuth2 Framework : API for securing REST resources (Ericsson Labs)

From www.slideshare.net - August 25, 2011 4:06 PM

The OAuth2 Framework allows you to protect your web resources using the next generation OAuth, (http://oauth.net/2/) as well as accessing OAuth2 protected resources, most notably the Facebook Graph API. The API consists of libraries for building your own OAuth2 server as well as client side access. The standard is still in draft mode so expect some level of changes. Currently version 10 of the OAuth 2 specification is the one being supported.

API page here : https://labs.ericsson.com/apis/oauth2-framework/

more...

No comment yet.

Scooped by Nicolas Weil

Scoop.it!

A new Internet-Draft for "RESTful Authentication Pattern"

From tools.ietf.org - August 20, 2012 9:37 AM

This document proposes a "RESTful" pattern of authentication for HTTP/1.0, 1.1, and 2.0. The existing 401 status code and WWW-Authenticate header are used to indicate that authentication is required and for negotiation purposes. The client POSTs an initial authentication message to an indicated login URI, and reply messages are returned as new representations of a session resource named by a session URI.

This approach has a number of benefits: it can be implemented with or without help from the HTTP stack, it can be universally implemented on the server side using the Common Information Gateway (CGI) and FastCGI, it results in a session Uniform Resource Identifier (URI) that can be DELETEd to logout, it is completely orthogonal to any HTTP "routers" and proxies, and it naturally (i.e., without changing HTTP) handles multi-legged authentication mechanisms.

Among other features supported are: channel binding, an optional round trip optimization for challenge/response mechanisms, somecryptographic protection options for clients that don't use Transport Layer Security (TLS), stronger authentication of servers/services to users (where authentication mechanisms provide that) and more.

more...

No comment yet.

Scooped by Nicolas Weil

Scoop.it!

REST-ful URI design best practices

From redrata.com - June 20, 2012 4:01 AM

What are the criteria for a good REST-ful URI?

- Short (as possible). This makes them easy to write down or spell or remember.

- Hackable ‘up the tree’. The user should be able to remove the leaf path and get an expected page back. e.g. http://example.com/cars/alfa-romeos/gt you could remove the gt bit and expect to get back all the alfa-romeos.

- Meaningful. Describes the resource. I should have a hint at the type of resource I am looking at (a blog post, or a conversation). Ideally I would have a clue about the actual content of the URI (e.g. a uri like uri-design-essay)

- Predictable. Human-guessable. If your URLs are meaningful they may also be predictable. If your users understand them and can predict what a url for a given resource is then may be able to go ‘straight there’ without having to find a hyperlink on a page. If your URIs are predictable, then your developers will argue less over what should be used for new resource types.

more...

No comment yet.

Scooped by Nicolas Weil

Scoop.it!

How REST replaced SOAP on the Web: What it means to you

From www.infoq.com - October 20, 2011 11:45 PM

Anyone working on enterprise systems in the last 10 years will remember the initial tenets of Service Orientated Architecture were to decouple applications and to provide a well defined service interface, which can be reused by applications and composed into business processes. The idea of reuse and composition made SOA an attractive proposition that sent thousands of organizations on a very challenging treasure hunt. We have since read SOA's obituary and its resurrection with many stories of woe peppered with some success, but with very few achieving the holy grail of SOA. Meanwhile, the web has essentially become a service oriented platform, where information and functionality is a available through an API; the Web succeeded where the enterprise largely failed.

This success can be attributed to the fact that the web has been decentralized in its approach and has adopted less stringent technologies to become service oriented. Many early APIs were written using SOAP but now REST is the dominant force (though some are more REST than others). The publication of REST APIs has been rapidly increasing.

more...

No comment yet.

Scooped by Nicolas Weil

Scoop.it!

Where is the SOA in REST-based SOA?

From www.zapthink.com - September 18, 2011 5:16 AM

While many architects believe that as an architectural style, REST is simpler and more straightforward that Web Services-based SOA, our research is turning up continued confusion over the principles of REST and how best to implement them. Everybody seems to get the basics—operate on resources at URIs with the four HTTP-centric operations GET, POST, PUT, and DELETE—but most people seem to miss the subtleties. Combine that confusion with the fact that you can do REST without SOA, the specifics of REST-based SOA are even more elusive, as we must pare down the essentials of both REST and SOA to understand the true nature of the combined approach.

How, therefore, should we handle Service abstractions, contracts, and compositions – arguably, the essence of SOA – in a REST-based SOA world?

more...

No comment yet.