SOA Probe

REST Web Service API Guidelines

2017-05-08T16:04:00.000+01:00

When building web services, one of the primary benefits of using REST over SOAP is the intuitive nature of service interfaces. However, this simplicity of interface can very easily be eroded. Below are some suggested (and hence flame proof) guidelines that could be followed to ensure continued interface simplicity:

Resource-Oriented

REST is resource-oriented, not service-oriented. Resources are nouns, not verbs.

Addressable

Every resource must be addressable by means of at least one URI (name). Names must be meaningful.
Clients cannot access resources directly - they deal in representations of that resource (e.g, XML, JSON, ...)
Resource representations would ideally be addressable (so that they can be passed around as URIs, eg. /rest/bookmarks.xml) The use of HTTP accept headers to specify representation is however acceptable, but should be provided as well as the addressable URI.

Stateless

Resource state must not be confused with application (client state). Resource state should remain on the server, while application state should remain on the client.

Connected

Resources should refer to other resources by means of their URIs.

Uniform Interface

All interaction between clients and resources should be via the basic HTTP methods, preserving the semantics of those methods.
GET: a request for information about a resource, delivered as a set of headers and a representation
HEAD: like a GET, but only headers are required in response
PUT: an assertion about the state of a resource, usually with a representation which the server will use to create or change the resource. PUT without any representation is an assertion that the resource should exist at that URI
DELETE: an assertion that a resource should no longer exist, and should not include a representation
POST: is an attempt to create a new resource from an existing one, the existing resource being a parent of the new one (in a data structure sense), or a factory resource whose purpose is to generate other resources. May also be used to append to the state of any existing resource.
OPTIONS: rarely used, but is an attempt to discover which subset of the universe a resource supports.
Consistent use of HTTP status codes (more on this in a future post)

Safety and Idempotence

GET and HEAD requests must be safe, i.e. make no change to the server state, and should not have any material side effects.
PUT and DELETE requests must be idempotent, i.e. repeatable

Multiple Representations

The address of a resource can return several representations of the resource. The client tells the service which types of representations it can understand and the priority order in which it would like to receive them.
All response content should be in JSON or XML according to HTTP Accept header, or failing that, request parameter format=xxxx. Default response format in the absence of a requested format should be JSON.

The Importance Of Simplicity

2017-05-07T21:56:00.001+01:00

I remember way back when, a number of colleagues engrossed in the latest Obfuscated C++ challenge, an exercise in making code so concise, so cryptic, that even the hardened coder paled.

This always struck me as an odd thing to want to do. Why make things more complicated than they have to be? Are code simplicity and readability not the important thing? After all, software only spends a small fraction of its life being created. The rest of the time it is being maintained, and usually by different people who are not going to appreciate your obscure brilliance.

Keep it simple, smart-arse.

Generalising Specialists

2017-05-07T12:31:00.003+01:00

There is this rumour going around that good architects need to write (production) code. I think the term was coined by Scott Ambler of agilemodeling.com, or was it ThoughtWorks? Anyway, I don't care, because I disagree, quite a lot.

See, I did write code, a lot of it. I was good at it, and I still like to write code for my own pleasure, but my current, full-time role as an enterprise architect does not involve much coding. As a result, I have become slightly detached from the way code is written in our company (tools, processes, etc.) and when I do, it is laborious and frustrating. In fact, I would respectfully suggest that letting me near production code might: a) not be the best use of my time, b) be dangerous.

It's not because I'm older, or wiser, or slower, or too important to code. It's because I spend my time thinking about different abstractions: higher-level ones. The principles are the same, but the moving parts are larger.

See, I write enterprise code.

My IDE is Powerpoint ... or Word, if I'm feeling dangerous.

I am like the town planner. Sure, I could have a go at building a house, but would you really want to live in it?

I know I wouldn't.

Black Ops Projects

2017-05-07T12:19:00.002+01:00

I think good project portfolio management is an essential discipline for software development.

You have to know what you want to do, why you want to do it (in terms of measurable benefits), how much it is likely to cost, know who will do it, know when it will be done, how much it ended up costing, and how much benefit actually was realised.

Then you have a defined pipeline of work, and software developers wake up in the morning knowing what they are supposed to be doing.

Enter the villain.

Our villain has a vague, but very senior role. He is responsible for improving something or the other, and is brimming with vision, personality and the gift of the gab. He has no time for pipelines. His ideas are hot, relevant and need to be done now! (Before he forgets them or moves on to the next grand scheme)

Our villain likes to pick on vulnerable teams, all smiles, and uses his charm and lofty position to lure or bully them into his cause. He gets things done. Under the radar.

He is dangerous.

He needs to be taken out.

Illusory Comforts

2017-05-07T11:53:00.001+01:00

I like process.

I appreciate that this is probably because it's in my nature to like order and predictability, but good process adds value, can often be automated, and frees up developers to do what they do best: create excellent software.

Bad process on the other hand is a killer.

It's a killer because it slows everything down.

It's a killer because it doesn't work, and is often bureaucratic.

But mostly it's a killer because it gives those in charge the illusion of progress.

I worked with a place once that outsourced their software development capability to an outfit that had CMM level 5 accreditation, and could prove it ... but developed the worst software I had ever encountered. Yet senior management were blissfully unaware of the fact, or perhaps they were and didn't care. They had achieved their outsourcing objectives, reduced resource costs, and achieved CMM level 5 in the process! I bet bonuses were good that year.

A bad leader does not trust his team to do their job. He tries to measure them, to enforce success via metrics and bad process. It offers him an illusory comfort of progress to see the hours worked and lines of code per day metric increasing, but damn those inconvenient holidays!

A good leader understands that his team consists of people, not resources. Humans who need autonomy, mastery and purpose. Motivated individuals who will take pride in their work, and do their best to get the job done well.

And that's all you can ask of them, really.

Correctly Assessing Security Risk

2017-05-06T12:09:00.000+01:00

I found a security issue some time back, the logging of a long-lived security session token. This token enabled me to access an internal client data service which only checked the validity of the token, not its right to perform the operation on the data I was accessing. We had two types of tokens, managed by the same session token management service, one for clients (the type of token I had found in the logs), and one for trusted internal service accounts. The client service did not care about the difference, and as a consequence I was able to access all client data with my token.

I raised a critical incident, but surprisingly, nobody raised an eyebrow, not even InfoSec. In fact, I was asked why I (little old me) was raising a critical incident. After all, was there a crisis? The incident was closed immediately and I had to instead raise a work item against the relevant team, who only fixed it some weeks later - there were more pressing delivery deadlines to consider.

Then, a week later, I found that some system was logging client passwords when they were changed. This was clearly a critical incident, but I thought twice about raising it. But I did, and boy did that stir the pond! InfoSec were all over it, sending out a flurry of messages to senior management, and the issue was fixed that day.

Yet both incidents were critical. Had I not used my trusty OWASP risk rating methodology spreadsheet to come up with an objective risk assessment for both? You see, the ability to leak all our customer data is just bad as the ability to log in to a few accounts and cause mayhem. We had strict money laundering controls, so financial theft was not the main threat, brand reputation damage was.

So what the hell was going on?

I think the issue is that of understanding security risk. Most people can relate to a password breach, but the other breach was too technical for the average punter. And there was the rub.

I think the answer to this is to establish rules like: if the risk rating is determined objectively to be critical, then it is critical, not: do I think it is critical? Granted, some of the inputs into the OWASP risk rating model are subjective, but they are less technical, and thus harder to get completely wrong.

It has been suggested to me that the business needs to accept the risk, but are they really qualified to do so? Surely it is InfoSec who, on behalf of the business it serves to protect, has to define and enforce SLAs for security risks?

Uniform Service Authentication and Authorisation

2017-05-05T23:08:00.000+01:00

The problem with using short-lived access tokens to enable authentication and authorisation of service requests, is that they only really work for synchronous interactions which themselves are short-lived. Access tokens in, potentially long-lived, asynchronous messages run the risk of expiring.

An interesting alternative is to use certificates to sign (and optionally encrypt) messages. For example, service A sends a message via some number of queues to service B. Service A has a private certificate which it uses to sign the message. Service B receives the message, and uses the corresponding public certificate to validate the message signature, and since this would only work with Service A's public key, service B knows the message originated from service A, and can authorise the request accordingly. This would work equally well for synchronous calls.

Of course, this means a lot of certificates deployed to a lot of places, but certificates could be obtained from a central service, and access control applied.

So service identity is sorted, but would about user identity?

I suggest that users and core services need to be separated by a gateway layer (application or service), which would be responsible for establishing user identity via some means (basic auth, OAuth, Kerberos, or whatever), and then sending a signed user identity assertion (along with any roles it might have) along with requests and messages, much like is done in SAML. Downstream services would trust the gateway to appropriately establish this identity, and trust would be ensured by means of the above certificate mechanism.

If you're looking for an identity & access management system, then check out OpenAM. ForgeRock are doing an excellent job of supporting it, and the major releases are open sourced and free to use. We use it at IG for SAML, OAuth, Windows SSO (Kerberos), LDAP authentication amongst other things. It is very easy to configure, either manually or scripted (e.g. via Puppet), and provides us a resilient, scaleable, standard authentication capability. It does also provide policy based access management, but we've not ventured there yet.

And there it is.

I Hate Documentation!

2017-05-05T21:00:00.000+01:00

For a software architect, and someone who tinkers with words, this is perhaps an odd thing to say, but it is true: I hate documentation.

I hate it because it is laborious, very often serves no purpose other than to have been produced, and rapidly gets out of date. I have followed methodologies where every model under the sun is produced, code is generated, and round-trip engineering is attempted. What were we thinking?

But documentation can add value. Code is a very low-level, cumbersome way to get to grips with a system. A few high-level component or sequence diagrams can add a lot of value. Documentation helps you to navigate a system, and understand why something was built.

So what to do?

I think the first thing to do is to distinguish between transient and permanent documentation.

Transient documentation is correct at a point in time, and very often only exists on a whiteboard. It serves to help think about a solution, but has a very short life span. After it has served a purpose, it gets to rest in peace in some archive.

Permanent documentation, however, continues to exist alongside the system, a living description that helps one to understand what was built. Permanent documentation needs to be owned and managed. And being managed, needs to be kept up to date. This means that if a project impacts the system, the owner(s) of the permanent documentation of that system need to be notified, so that the documentation can be updated. Of course this is costly, so you do it only to documents you care about.

But this is not the end of the story. Generating navigable documentation from your systems is a powerful way of supplementing your formal documentation. For example:

using tools like Swagger to generate invokable service interface documentation.
using deployment scripts to publish deployment information to configuration management database systems such as Service Now.
using application performance monitoring technology like AppDynamics to show system deployments and interactions.
using standardised logging and log aggregation (operational intelligence) tools like Splunk to help trace message flows through systems.

Evil Session Tokens

2017-05-05T14:24:00.003+01:00

So we build a new web application, SIMPLES.COM. Clients login, over HTTPS of course, and a session token is issued. Since we don't want the client to have to log in frequently, we give the token a long lifetime, or at least a way of using it to get a new one.

The application will have to persist the token on the browser, so cookies are used. We consider using browser local storage, but cookies seemed the best way to guarantee wide browser compatibility.

The application then validates every HTTP operation, using the session token in the cookie, and authorises access as appropriate.

Sorted.

Enter the hacker.

Client Joe Bloggs receives an email with a phishing link to dodgy website S1MPLES.COM (note the name is different), and clicks on it. Joe is taken to a page where a few sneaky GET requests are sent to the real SIMPLES.COM website, and Joe's browser helpfully supplies the session cookie, since it's the correct domain, and the hacker now has access to Joe's data.

How do we fix this?

The first thing to do is not use cookies for authentication. The web app must attach a session token header to each request. That way the above Cross-site Request Forgery attack is not possible.

However, we now have a long-lived session token being passed around, but that's OK, because we use HTTPS.

Except we don't. Not all the time.

SIMPLES.COM is accessible over HTTP. Only the login page and secure site are via HTTPS.

So Joe, being a lover of coffee, and free WiFi, gets caught by a man-in-the-middle attack by Mr Evil with a portable WiFi router. Mr Evil intercepts the requests, and the session session token sent with each request.

Mr Evil now has full access to Joe's account, for a long time.

The answer is to make SIMPLES.COM full HTTPS, and to use HSTS to ensure no opportunity for man-in-the-middle exists. And to add all the recommended security headers, e.g. content security policy.

Cool. Mr Evil shrugs, and picks on someone else.

Much later, Mr Bored Developer is browsing through the application logs (helpfully made available via a log aggregator), when he notices that the session tokens are logged for all to see.

Not so cool.

So what do we do?

One way is to use an OAuth approach to issue not one session token, but two: a short-lived access token, and a long-lived refresh token. The refresh token is stored in the application browser, but is never used for access, only to request new access tokens.

Of course these access tokens could still be leaked, but being short-lived, should expire very quickly.

Much better.

P.S. Please, please don't build your own security solutions! Spring Security and mature open source identity and access management systems such as OpenAM are a much better way to go.

Application Security Function

2017-05-05T11:29:00.000+01:00

Application Security is the software development concern of proactively ensuring that the applications being built, and integrated with, are secure. This will require that application security becomes a standard focus for all software development teams, along with delivery, architecture, and quality assurance.

I suggest that this needs to be achieved through:

Education

Everybody (including the business and delivery) needs to understand the importance of security. At IG we had a very positive recent experience with a consultant who came into our offices, spent some time with our development teams, educating and instilling enthusiasm for the subject, and then closing with a company-wide demonstration of our application vulnerabilities at the time. The presence of C-level executives at these demonstrations lead ultimately to the creation of an application security function (in addition to our already quite mature InfoSec function).

Standardisation

Adopt industry guidelines such as OWASP to ensure a consistent, best-practise approach to security.

Organisation

Security, like quality, does not happen by accident, and requires organized effort to achieve. Create a team of security champions, whether physical or virtual, to:

collaborate on application security decisions
raise awareness of application security best practice in development teams
help teams understand application security threats via threat modeling
help teams secure their applications via security test suites
provide a developer communication and feedback loop on security matters
collaborate closely with InfoSec, PMO and Operations to ensure appropriate goal alignment - resourcing security work will be a key challenge

Process

Integrate security with your software development lifecycle, specifically:

create an effective security monitoring, incident, tracking and resolution process
prioritise issues using the OWASP risk rating framework
require teams to maintain security threat models for their applications
create security cheat sheets and code review checklists
create automatic security test suites

Testing

Testing is the only way to confidently assert that an application meets its requirements, and this is no different for application security. All applications should be required to have automated security test suites with adequate coverage. In addition, periodic, independent 3rd party penetration tests and architecture reviews should be performed.

The Challenge

Doing security is like taking out an insurance policy. You don't have to do it, and might get away with it, but can you afford the consequences if you don't?

What do you have to lose?

Probably a lot.

Security-oriented Architecture

2017-05-04T17:25:00.000+01:00

Split your monoliths into myriad services and suddenly your established security boundaries fizzle into non-existence.

I would assert that all services need to think about security, namely:

authentication: who is calling me?
authorisation: are they allowed to call me? are they allowed to request this particular data?
validation: is the message valid?
confidentiality: is my sensitive data secure? what is sensitive data?
integrity: how do I know the request has not been tampered with?
non-repudiation: how do I know the request came from a legitimate source

Yes, all services, even the internal ones. Don't think of hackers as spotty teenage opportunists. Think of them as sophisticated criminal organisations that spend millions on stealing precious corporate data, or threatening brands with ransom attacks. Loyal as I'm sure your staff are, are they immune to greed, revenge or blackmail?

That's not to say you might not answer the questions above differently for internal services, as opposed to edge-facing ones, but consider these issues you must.

Microservices: New spin, old hat?

2015-03-24T10:50:00.000+00:00

This year's QCon 2015 conference in London was abuzz with talk of microservices, and if you, like me, have seen protocols and standards like CORBA, RMI, J(2)EE and SOAP come (and go), you would be forgiven for sighing and thinking "what's new"? However, it seems that Google, Amazon, eBay and others would beg to differ.

In a nutshell, microservices:

Are small (they fit in your head)
Run in their own process
Are independently replaceable, upgradeable and deployable via automated/test deployment mechanisms
Are backwardly (and forwardly) compatible
Communicate with each other via lightweight mechanisms, typically an HTTP resource API
Are organised around business capabilities. "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." -- Melvyn Conway, 1967
Involve products, not projects
Require decentralised governance
Require decentralised data management (independent persistence)
Automate their infrastructure (e.g. AWS)
Are designed for failure of dependent services
Prefer asynchronous calls to synchronous ones
Involve evolutionary design
Are fully developed, owned and supported by single teams
Compete with each other in a market-place

Much of this will be familiar, but what is new and very interesting is the degree to which microservices apply the familiar principles of loosely-coupled, encapsulated software components to the organisation developing and managing those components.

Traditionally structured companies will balk at all of this, and perhaps dismiss this as yet another architectural fad, but I'm not so sure. Check out these two excellent videos on Spotify's Engineering Culture.

Further reading:

Supporting Your Public Web API

2015-03-16T14:21:00.003+00:00

No matter how beautiful and well-designed your new web API is, unless it is well supported, you may find that you become a victim of your own success. Below are 4 suggested key elements of a supportable web API, based on my experiences at IG.

1. Documentation, documentation, documentation!

Unless it is easier to refer to your API documentation than to contact you, you will be contacted. Don't assume anything is obvious. Document your API in detail. Define your business terms. Explain common interaction patterns. Provide client code snippets and working samples in a variety of language bindings. Provide a FAQ.

Consider providing a client SDK (Yes,I know REST is meant to be easy, but the reality is that unless your client is already a developer, they will struggle. Make it easy for them to use your API.)

Consider providing a moderated forum to allow clients to answer each other's questions. Provide an interactive API explorer allowing clients to try out APIs and see the raw HTTP requests and responses.

2. First and Second Line Support

Provide a "contact us" form instead of direct phone numbers. The page should encourage clients to refer to API documentation, FAQ, and forum (if one exists).

Provide first line, "customer sensitive" support to answer common queries, or at least to ensure queries are well formulated before passing onto second line support. If your organisation already has a customer services help desk, use them! They may balk initially at the perceived technical nature of the support, but should be helped past this by through training and provided access to simple debugging tools, e.g. the API explorer or a facility to search service log files.

Provide dedicated second line support via a rota consisting of the developers who built the API.

Maintain a searchable log of frequently answered questions (and answers). Update the public FAQ from this log.

3. Effective error handling

Give API clients as much error information as possible in request responses. If inputs are incorrect - tell them why. If error codes are used - ensure these are documented.

Log every request in detail, including request authentication headers and body (subject to client privacy constraints). Use a transaction id pattern to allow the flow of API requests to be tracked across multiple back-end systems. Provide easy access to system logs, e.g. via Splunk, which provides a searchable index over a number of configured log files. Splunk additionally allows requests to be charted and management dashboards to be created. Senior management will want to know just how popular the API is.

4. Provide a barrier to entry

If, despite all of the above, the demand for your API is still overwhelming, consider:

throttling your API, with chargeable tiers for increased quotas
requiring that a verified account to be opened before an API can be used
providing support to valued customers only (or on a subscription basis).

What is SOA?

2015-01-14T16:33:00.000+00:00

What is SOA? SOA or Service-Oriented Architecture is a software architecture pattern in which applications or systems are constructed from underlying (and usually distributed) software services that conform to a specific set of characteristics, namely:

1.Contract based
2. Location transparency
3. Autonomous
4. Abstract
5. Reusable
6. Composable
7. Stateless
8. Discoverable
9. Extensible
10. Loosely coupled

The primary goal of SOA is software development agility, i.e. the ability to respond the change easily, and cheaply, thus allowing businesses to rapidly respond to changing markets.

Services are typically (but by no means exclusively) implemented as web services, i.e. they operate over the ubiquitous web HTTP protocol, and are implemented either using XML-based SOAP or the lightweight (and more popular) REST paradigm.

The highly distributed nature of this architecture has resulted in a need for a runtime platform (the Enterprise Service Bus, ESB) to help manage the operation of these services, but also to handle complex enterprise integration scenarios involving multiple (and often legacy) platforms, protocols and security models - products like Oracle Service Bus or the open source Mule ESB.

In addition to being an integration solution, the service-oriented pattern also offers an opportunity for easier implementation of high-level business processes using Business Process Management (BPM) solutions that are often offered as part of the ESB product suite.

Service-oriented architecture is highly relevant to the rapidly growing cloud computing model where applications are built in the cloud as orchestrations over public cloud-based APIs, and we are seeing ESB vendors like WSO2 and MuleSoft in or moving into this space, offering cloud-based versions of their products, as well as API management products.

Some will argue that SOA is not new, and that distributed programming involving services has existed for a long time, and they are right. However those early efforts stumbled on the hurdles of platform incompatibility and standards complexity. Now, with ubiquitous, and easy to use protocols like REST, web service API development is growing rapidly, and the integration possibilities seem endless.

(What is SOA, Service Oriented Architecture)

REST Web Service Paradigm Shift

2015-01-14T16:32:00.000+00:00

Moving your Service-Oriented Architecture (SOA) from RPC style (web) services to SOAP document-oriented services, or REST resource-oriented services requires a difficult mental paradigm shift. The same kind of shift that was required for monolothic and procedural programmers to move to object-oriented programming styles. This change is not easy, and not all will pass muster. Failing to make the change will mean the difference between Just a Bunch of Web Services (JABOWS) or a fully-fledged SOA.

Ensuring that this mind shift does happen will require good organisation and strong, well-articulated guidance and governance. Until the new pattern becomes habit, people will very quickly slip into old habits.

Below are some guidelines and implementation suggestions from this blog:

Favourite Funny Programming Jokes

2014-09-06T12:08:00.003+01:00

“Knock, knock.”
“Who’s there?”
...very long pause....
“Java.”

Programming is like sex:
One mistake and you have to support it for the rest of your life.

The generation of random numbers is too important to be left to chance.

Two strings walk into a bar and sit down. The bartender says, “So what’ll it be?”

The first string says, “I think I’ll have a beer quag fulk boorg jdk^CjfdLk jk3s d#f67howe%^U r89nvy~~owmc63^Dz x.xvcu”

“Please excuse my friend,” the second string says, “He isn’t null-terminated.”

A programmer was crossing a road one day when a frog called out to him and said, "If you kiss me, I'll turn into a beautiful princess."

He bent over, picked up the frog and put it in his pocket. The frog spoke up again and said, "If you kiss me and turn me back into a beautiful princess, I will stay with you for one week."

The programmer took the frog out of his pocket, smiled at it and returned it to the pocket. The frog then cried out, "If you kiss me and turn me back into a princess, I'll stay with you and do anything you want." Again the programmer took the frog out, smiled at it and put it back into his pocket.

Finally, the frog asked, "What is the matter? I've told you I'm a beautiful princess that I'll stay with you for a week and do anything you want. Why won't you kiss me?"

The programmer said, "Look, I'm a programmer. I don't have time for a girlfriend -- but a talking frog, now that's cool!"

Excel REST Trading API Example

2014-07-10T09:23:00.000+01:00

As much as I have a love-hate relationship with Microsoft, I have to admit the Excel has won me over as a power-user tool, particularly in the world of finance, where it may be used to access powerful back-end analytics servers to provide real-time yield curves and such like.

REST APIs such as IG's Web Trading API make this even easier, as this Excel VBA code snippet to get a list of open positions will hopefully demonstrate. The sample assumes that a login /session request has already been executed and the client and account session tokens have been obtained. The API key is the unique authorisation token required to access the API.

Public Function positions() As Collection

' Set up the HTTP access framework
Set oXMLHTTP = CreateObject("MSXML2.XMLHTTP.6.0")
' Set the API URL
Call oXMLHTTP.Open("GET", IG_API_HOST + "/positions", False)
' Set the HTTP request headers:
' Set the account session token
Call oXMLHTTP.SetRequestHeader("X-SECURITY-TOKEN", m_accountToken)
' Set the client session token
Call oXMLHTTP.SetRequestHeader("CST", m_clientToken)
' Set the API key
Call oXMLHTTP.SetRequestHeader("X-IG-API-KEY", m_apiKey)
' Set the content type to JSON
Call oXMLHTTP.SetRequestHeader("Content-Type", "application/json; chartset=utf-8")
' Set the requested response type to JSON
Call oXMLHTTP.SetRequestHeader("Accept", "application/json; chartset=utf-8")
' Execute the request
Call oXMLHTTP.send

If oXMLHTTP.Status = 200 Then
' Successful. A list of zero or more positions will have been returned
' Extract the response as a JSON object
Dim data As Dictionary
Set data = JSON.parse(oXMLHTTP.responseText)
' Get the list of positions from the response object
Dim positions as Collection
Set positions = data.Item("positions")
' If positions exist, iterate over the list If Not positions Is Nothing Then
Dim aPosition As Object
' Do something with the position, e.g. extract the instrument name of the underlying market
For Each aPosition In positions
Dim instrumentName as String
Set instrumentName = aPosition.Item("market").Item("instrumentName")
' etc
Next
Else
' An error occurred
MsgBox oXMLHTTP.responseText
Set positions = Nothing
End If

End Function

IG REST Trading API

2014-06-30T17:48:00.000+01:00

Hot off the press is the news that IG (my esteemed employer) has launched its REST Trading API.

The API provides REST-based and streaming access to a range of popular asset classes (including indices, forex, commodities, binaries and options), and includes functionality to:

Trade using risk management tools such as stops and limits

View real-time and historical market prices

Analyse market instrument and client sentiment information

Review account balances and trade history

IG already offers a well-established FIX API for corporate clients, but now with its new REST Trading API, IG's technology platform becomes much more easily and widely accessible, allowing for example:

Corporate partner integration without the start-up costs and complexity of FIX
Trading strategy automation
Retail trading app development

The REST Trading API labs site offers getting started guides, API documentation, a downloadable sample trading app, and an interactive API companion app for trying out the REST APIs.

The API will only be available in the UK initially, but the wider roll-out is imminent, so be sure to follow the labs site on Facebook or Twitter for updates.

Related:

· ComputerWorld: IG opens up web API to allow traders to develop own financial apps

· Finextra: IG opens up Web API to let traders build own apps

· Forex Crunch: IG Labs aims to give traders more control of the way they trade

· ForexMagnates: IG Opens API to Public Development, Launches IG Labs

· FOW.com: IG rolls out new tech offering for traders

Layer 7 on REST API Error Handling

2013-02-19T11:14:00.003+00:00

Layer 7 Video on REST API Error Handling

Apigee on REST API Design

2013-02-19T11:03:00.002+00:00

Apigee Presentation Video on REST API Design

WS02 REST API Management

2013-02-19T09:47:00.004+00:00

REST & API Management with the WSO2 ESB from WSO2

REST Web Service Spring Error Handling

2012-12-20T14:06:00.001+00:00

The Spring framework provides excellent support for building REST web services in a service-oriented architecture (SOA), as I have demonstrated in a previous post, but what is not immediately obvious is how best to deal with errors. Instead of throwing raw exceptions to the client, one would prefer to return a well-formed response consisting of an appropriate HTTP status code and a meaningul response body containing a structured error message in the response form (JSON, XML, ...) requested by the client.

For example, assuming you have a basic REST endpoint such as:

 @RequestMapping(value = "/samples", method = {RequestMethod.GET})
 @ResponseBody
 public SampleList findAllSamples() throws SampleException {
  return new SampleList(service.findAllSamples());
 }

It is good practice in general to not let implementation exceptions leave the service tier, so you might use aspects to catch these and rethrow them as service exceptions. The code below catches a ReferenceNotFoundException from the data access tier and throws a service exception with the reference number and setting the desired http status code. Another good practice is to avoid sending free text error messages to a service client, and instead to send structured messages that can be dealt with or rendered as the client sees fit.

@Aspect
@Component("exceptionHandler")
public class ExceptionHandler {

   /**
    * Exception handler for ReferenceNotFoundExceptions
    * 
    * @param nfe the exception being handled
    */
   @AfterThrowing(pointcut = "execution (* com.sample.service.*.*(..))",

                                              throwing = "nfe")
   public void handleNotFoundException(ReferenceNotFoundException nfe) {
      throw new SampleException(
         new ReferenceNotFoundError(nfe.getReference()),

                               HttpStatus.NOT_FOUND);
   }

Now to map the service exception (SampleException) to a meaningful HTTP response using the Spring 3 @ExceptionHandler annotation:

   @ExceptionHandler(SampleException.class)
   @ResponseBody
   public SampleErrorList exceptionHandler(SampleException se,
                 HttpServletRequest req,
                 HttpServletResponse res) throws IOException {

      res.setStatus(se.getHttpStatus());

      return new SampleErrorList(se.getErrors());

   }

It is also possible to set the HTTP status code using an annotation, but in this example the exception determines this, so the handler sets it programmatically.

See here for a downloadable working sample.

REST Web Service Spring Error Handling

Funny SOA Joke?

2012-12-07T09:30:00.002+00:00

“Knock, knock.”

“Who’s there?”

... very long, expensive pause ....

“SOA”

How my wife explained ESB to me

2012-11-27T11:53:00.000+00:00

Wife: I've been thinking...

Me: (Oh no... what now?) Well done! ... Ouch! ...

Wife: That service thingy you told me about the other day... lots of little services all helping each other out...

Me: Service-oriented Architecture. What about it?

Wife: Well, it's a nice idea in principle, but sounds like it would be a nightmare to manage. A bit like a juggler trying to cope with lots of objects in the air, all different shapes and sizes...

Me: That's a really good analogy. Yes, service-oriented architecture needs a juggler. They call it an ESB or enterprise service bus.

Wife (laughing): You men and your three letter acronyms.

Me: It's actually quite a cool concept, a bit like a telephone switchboard. Services are connected in flexible ways via the bus, without being physically connected to each other. The bus looks after the connections, and can reroute calls when connections fail for example.

Wife: Like an automatic switchboard operator.

Me: Yes, exactly! You're fabulous, you know?

Wife: You've only discovered that now?

Me: Er...

How I explained SaaS to my wife

2012-11-26T08:52:00.000+00:00

Wife: You've been staring at that screen for ages. What are you doing?

Me: Thinking about writing a post on SaaS.

Wife: On what?

Me: Software As A Service.

Wife: Is that what you were telling me about the other day? Service-oriented thingy?

Me: Service-oriented Architecture. Yeah, it's similar, but instead of little services which you can use to build your program, you get a whole program as a service. Imagine Excel on the internet - or the "cloud" as it's being called - you don't have to install it on your computer, you just go on the internet to use it.

Wife: The internet? Isn't that slow?

Me: It can be, so you need to be careful what kind of programs you do this with. For instance, there's a company called SalesForce who offer a Customer Relationship Management program via SaaS. Companies use it because it saves them having to install and manage lots of computers to put this big program on.

Wife: Interesting...

Me: Are you being sarcastic again?

Wife: No, not at all. I'm just wondering if they do HaaS?

Me: What?

Wife: Husband As A Service. I still need that light upstairs fixed.