Skip to Content

REST (which stands for REpresentational State Transfer) is an architectural style that is informed to a large extent by, but theoretically not limited to, the HTTP application protocol (yes, _application_ protocol, not transport protocol!). As an approach to application integration, REST has often been compared to its ‘rival’ Service Orientated Architecture (SOA), although a RESTful approach to integration architecture known as Resource Orientated Architecture (ROA) might be a better comparison fit.

Fans of REST and ROA (I’m one of them!) state many advantages over SOA, such as:

  • loose coupling vs tight coupling
  • flexible vs brittle interfacing
  • simple vs complex implementation
  • easier vs harder to debug

and subtly, but importantly, ROA is a lot more deserving of the word “Web” in the phrase “Web Services”, as it works and flows _with_ Web concepts, rather than, as in the case of SOA, fighting *against* them. SOA, incidentally, has been referred to as “CORBA with angle brackets”, which is as funny as it is true.

REST concepts and ideas have been around SAP for quite a while now; there is of course some coverage here on SDN, such as:

Forget SOAP – build real web services with the ICF” (me, Jun 2004)

Real Web Services with REST and ICF” (me, June 2004, again)

REST Web Services in XI (Proof of Concept)” (Wiktor Nyckowski, Mar 2009)

A new REST handler / dispatcher for the ICF” (me, Sep 2009)

VCD #16 – The REST Bot: Behind the scenes” (Uwe Fetzer, Sep 2009)

REST-orientation: Controlling access to resources” (me, Sep 2009, again)

and recently:

Put SOAP to REST using CE” (Werner Steyn, Nov 2009)


What especially delighted me was the coverage that REST concepts and ideas got at SAP TechEd 2009 in Vienna. Lots of people were talking about it, and mentioning it in presentations. Over half the DemoJam contestants mentioned REST too. I personally had a fascinating and very rewarding chat with SAP guru Thomas Ritter during RIA Hacker Night, and have also corresponded with the very knowledgable Juergen Schmerder. It seems that there is a lot of interest in REST at SAP.

But what about REST _in_ SAP? How might you use it, be guided by it and ultimately _build_ things with SAP NetWeaver technologies? 

If you’re interested, you might want to attend our upcoming Mentor Monday session

REpresentational State Transfer (REST) and SAP – An Overview“, on Monday 25th Jan at 13:00-14:00 PST. 

You can get more information on the SAP Mentor Monday wiki page.

Hope to see you there!

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

    1. DJ Adams Post author
      Hi Gabriel, thanks for the info. I didn’t know, but I don’t have access right now, it seems, anyway. I’ll request it.


    1. DJ Adams Post author
      Hi Maarten

      I’m not sure of the context of the question, but if I understand correctly, the answer is that you implement PUT and DELETE exactly how you’d implement code for the other methods, i.e. check for the method first, then write code accordingly. As far as handling incoming HTTP requests, the ICF makes no distinction (nor cares, itself) as to what method is specified on the request.


        1. DJ Adams Post author
          Hi Maarten

          Ooh! I think there’s been some misunderstanding, sorry if I’ve confused you.

          The intended operation should NEVER be encoded in the URL (the ‘noun’). The operation should be explicitly stated by the use of the appropriate HTTP method (the ‘verb’), like you say in the second part of your comment.

          The ICM, or more specifically the ICF, gives you access to the HTTP method that was specified in the request.

          l_method = server->request->get_header_field( ‘~request_method’ ).

          (See for more info on pseudo header fields).



Leave a Reply