Saturday, July 28, 2012
Thursday, July 26, 2012
OAuth and API Providers: Come on Guys!
OAuth and API Providers: Come on Guys!: 
If you run a business and decide to become an OAUTH provider or support an API it is essential that you put as much emphasis on this portion of the product as you would on any other core feature.
Wednesday, July 25, 2012
Tuesday, July 24, 2012
On RESTful API Standards – Just Be Cool: 11 Rules for Practical API Development (part 1 of 2)
On RESTful API Standards – Just Be Cool: 11 Rules for Practical API Development (part 1 of 2): 
There are many articles floating around the internet right now about defining RESTful API standards. I’m guessing this is because Ruby on Rails makes it so easy to build an API that everyone and their mom has started building one.
RESTful API Server – Doing it the right way (Part 2)
RESTful API Server – Doing it the right way (Part 2): 
In the part 1 of the post, I introduced the RESTful principle and explained how to architecture your server code so as to ensure easier versioning and deprecation of your API. In this part, I’m going to talk briefly about HATEOAS and hypermedia and then show you the role it plays in a native mobile client development. But the crux of this post is going to be centered around how to implement caching (or rather server side support for caching). Target audience include, server developers and to some extent, iOS or any mobile platform developers.
Some Suggestions for Choosing a Token Format for RESTful Web Services
Some Suggestions for Choosing a Token Format for RESTful Web Services: 
The most important token format that you need to support for your web apis and RESTful web services these days is: anything. So many platforms define their own authentication/authorization mechanism with what seems to be little concern for standardized formats: API keys here, HMAC signatures there, various OAuth interpretation, etc. Simple does trump standards. For the integration-focused enterprise architect, this reality creates a need for flexible infrastructure supporting arbitrary token formats.
The value of HATEOAS for a read-only REST API
The value of HATEOAS for a read-only REST API: 
I’m neck deep in RESTful APIs. I’m in the late stages of designing the Analytics 2.0 APIs in my job as Product Owner for Analytics at Rally Software. I’m in the early stages of designing an API for the Lean Software and System’s (LSSC) Kanban Benchmarking and Research Program… and just today, I met with Steve Speicher and others from the Open Services for Lifecycle Collaboration (OSLC) to talk about joining one of the working committee designing RESTful services for data interchange.
Nobody Understands REST or HTTP
Nobody Understands REST or HTTP: 
The more that I've learned about web development, the more that I've come to appreciate the thoroughness and thoughtfulness of the authors of the HTTP RFC and Roy Fielding's dissertation. It seems like the answers to most problems come down to "There's a section of the spec for that."
REST is OVER
REST is OVER: 
Yep. Sorry to have to inform you. REST is totally over. The cool kids are moving on. We're building "Hypermedia APIs" now. Such is life.
How Should REST Services be Documented?
How Should REST Services be Documented?: 
REST has become the standard way of creating APIs and exposing resources on the internet. Traditional web services (using SOAP and various sets of WS-* standards) are still used a lot within enterprises, but have pretty much disappeared completely from the public API area and are replaced (or deprecated in favor of) REST based APIs.
10 things you should do to write effective RESTful Web services
10 things you should do to write effective RESTful Web services: 
With the popularity of REST Web services on the rise, developers need to know how to avoid pitfalls and make their services the best they can be.
REST APIs as Data Backends
REST APIs as Data Backends: 
Some months ago, the Socorro team agreed that our current mix of REST API middleware calls and direct SQL calls from the web interface simply wasn’t meeting our needs. We were faced with an increasing number of data sources, including the coming addition of Elastic Search to the data storage system, and maintenance was becoming a problem. Thus, the decision was made to move our data layer to our REST API exclusively, removing all direct access to data storage from the web interface.
Why My REST Service Doesn’t Work: Cross-domain Security, JSON, JSONP, and CORS
Why My REST Service Doesn’t Work: Cross-domain Security, JSON, JSONP, and CORS:
Why My REST Service Doesn’t Work: Cross-domain Security, JSON, JSONP, and CORS
Don't build the best REST API, build the best HTTP API.
Don't build the best REST API, build the best HTTP API.:
Rob Conery put out a challenge yesterday to some of the REST fans he knows to help show him what a REST API for his video learning site Tekpub would look like. I enjoy API design so I thought I’d take him up on the challenge.
REST and Urls
REST and Urls:
Rob Conery has been talking about REST lately, and I think he perpetuate a common misconception. In particular, in the post I referenced, he is asking about ideas for URLs for doing things like logging in, working with productions and episodes, etc.
To SOAP, or to REST, that is the question
To SOAP, or to REST, that is the question: 
Today I was asked to describe the difference between SOAP and REST web services and how to decide which one to use? Here is what I came up with:
REST (Representational State Transfer) and RESTful web services: Methods, Concepts and Examples
Representational state transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. As such, it is not strictly only a method of building what are sometimes called “web services.” The terms “representational state transfer” and “REST” were introduced in 2000 in the doctoral dissertation of Roy Fielding, one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification. The terms have since come into widespread use in the networking community.
REST - Can You do More than Spell It? (Part 1)
REST - Can You do More than Spell It? (Part 1): 
Thousands of years ago when we first started building web pages, things were very simple. You’d put some text on the page, maybe even an image, and that was pretty much it. But today it’s a whole different ball game. Instead of static pages there’s the dynamic applications we’ve come to depend on. And so, how these applications are designed to communicate becomes very important. In this series I’ll introduce you to the REST architecture style. In this article I’ll help you to understand exactly what it is, and later I’ll show you how it can be implemented in a PHP environment.
Pure vs Practical REST
Pure vs Practical REST:
This is a useful table I often go back to, comparing pure REST (such as HATEOAS) with the "practical" REST so often found in the field:
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.
ReST in Practice
ReST in Practice:
A little while ago I wrote a post about ReSTful web services and how they are distinct from a typical “HTTP done right” web service. I have heard complaints that the characteristics of a ReSTful web service (a given resource will have links to related resources which can be used by the client as state transitions) are only applicable when the client using it a web browser, and that therefore they are more applicable to web interfaces than web services.
Subscribe to:
Posts (Atom)