csctechtalk

Not being strict with the HTTP semantics!

Not explorable enough and may be not versioned

I mean if we move faster with changes and not allow our clients to migrate that can be a big problem

tunnel everything through POST

Very good point. How do we mitigate "running faster" than our customers? #csctechtalk #apiprogram

Versioning I believe is the answer

Don't pay attention to resource sematics as nouns - that's an easy way to make life harder for developers :-)

there are tools - swagger for example, or MukeSoft's RAML - many others too

@bassmanitram that's cool

Swagger is emerging as a defacto standard for design and documentation http://swagger.io

if the services are useful, APIs are just a way to provide them

APIs should be accessible to developers in a self-service way. The API #DX should be as delightful as the #UX for user interfaces

We want to be able to publish our APIs so others can use them, right? So that means our development community should embrace this... break down some silos. #csctechtalk #apiprogram

Reply to Abhishek Khandelwal, PMP The API is powerful when built by an open community and strengthened in both usability and functionally rich simplicity

@OhneMoose Need though and effective platform to communicate and let others use them

The business value is only bounded with by our imagination...There is a whole world of services to tap into.

reach new customers or increase the value of current customers by offering existing services via new platforms and devices

It adds great value to Mobile First approach

what was the value in it for twitter to open up their apis?

possible publicity by opening channels for different systems to interact with twitter

@sorincos opening up APIs lead to innovation.. people might found a new ways to use your APIs you may have never thought of

Mobile offers a very compelling value proposition for API consumption

@mridul_bansal Generally opening up more channels to your service.

Aditya: that's one more reason to think at HATEOAS only as suggestion, not as law

@sorincos the majority of twitter traffic comes via its APIs. Traffic == money

@quotedian but is HTTP traffic = money? Not necessarily. They offer the API for free and not get any penny for the bandwidth everybody uses for OAuth. But, they reap from the visibility they get this way.

so charging for the API is not always an appropriate strategy. It really depends.

+1 for positive and delightful developer experience #DX for API consumers. Self-service and no "out of band" information required

it enables assembly of numerous APIs to be integrated into existing well understood HTTP based offerings

An important consideration for running a successful API is use of a public/private developer portal. This is a feature of most API management solutions today and facilitates discovery and usage of APIs

I second this. APIs should (emphasis on should) make things easier, especially in solution composition. #csctechtalk #apiprogram

can we think of API Mashup??

Two possibilities. 1) Provide our own APIs to our services at a cost 2) Provide value added services to APIs from others.

Most certainly! That's a good way of explaining the benefit of opening up system with a flexible RESTful API!

We can create API eco-system, e.g. Insurance, which then can be provided to outer world so that they can consume payable services and can create plug ins etc.

with a well thought out and minimalistic API approach that can stand up over time avoiding incompatibilities, once its public and used, expectations drive responsibility

The API Store, made public plus the API store for our development teams to share and use each other's APIs #csctechtalk #apiprogram

Yes, but what is wrong with repackaging. They open whole new ways of doing things

APi eco systems for one

so an eco system can have broad implications. #csctechtalk #apiprogram

The other way around: Web services is one type of API

Very much an economic one.

APIs are an old concept, but what is different now? What about REST? Does this change the game? #csctechtalk #apiprogram

It has reduced many of the overheads which are typical to web services

Theoretically it shouldn’t. But the wide spread acceptance of REST has changed perceptions

APIs and specifically REST APIs are intended to make the Developer Experience #DX better and easier

Refer to Richardson REST Maturity Model http://martinfowler....

as old as they seem I don't see them widely adopted or in a very consistent way. Most of the time we stop half way

To me the important thing is how to API-fy something that is currently locked and what tools and technologies can help us automate that

If REST is used over HTTP, it does makes consumer's life easier

Has REST taken off more since it was adopted as the standard by many cloud providers?

I think so ! JIRA, ReviewBoard are few examples but there are many OSS and organization which are putting their energy behind REST

REST is taking off. It really enables simpler interaction but yet more powerful because of the constraints it makes on vocabulary (verbs).

Not sure of the constraint on vocab really is its strength .

There are enough discussions on e.g. when to use POST or PUT etc.