Remote API

Topics: Feature requests, General
Mar 7, 2012 at 10:34 AM

Hi

Some thougths/insights about Remote API ideas:

Remote API

Motivation

Remoting API and/or framework (through SOAP Web Services, REST, WCF, XML-RPC, protobuffers, U name it) for:

  • remote maintenance
  • batch editing/work

with: Nice-to-have to reuse existing Composite C1

  • CRUD stuff (all Ops - select, insert, update, delete)
  • for CRUD stuff security is essential (authentification/authorization API) 
    Idea is to reuse Composite C1 exisitng authentification/authorization API.

References

Documentation:

  1. Fronetnd FAQ - External functions - ASHX files: 
    http://docs.composite.net/HTML/FrontendFAQ?q=Can+I+call+C1+Functions+AJAX+style+from+JavaScript+or+Flash%3F 
    Caveat: "Read only" - CRUD needed with authentification and authorization 
    Suggestions?

Discussion list:

  1. http://compositec1.codeplex.com/discussions/263317
  2. http://compositec1.codeplex.com/discussions/263678
  3. http://compositec1.codeplex.com/discussions/256876
  4. http://compositec1.codeplex.com/discussions/250644

Status

  1. Implemented External Function with ashx 

    Bugs/features found: External Functions ashx - lowercase url - excption http://www.holisticware.net/HolisticWare/Know-How/development/Web/CMS/Composite-C1/Discussions/2012-03-07-External-Functions-ashx-lowercase-url-excption.aspx
  2. Implemented SOAP webservice
    1. in root of the application: http://host.domain/api/tools.asmx 

      Works OK, but no security
    2. behind/below Composite of the application: http://host.domain/Composite/api/tools.asmx 
      Currently getting redirects, but working on it! 
      Before going further, any suggestions/ideas. Composite C1 uses SOAP a lot this would be nice-to-have...

regards

 

mel

Mar 7, 2012 at 11:16 AM

isn't soap a bit last century stuff... have you looked at Web API? 

I'm not sure standard Composite Console security would be sufficient for a proper Remote API. You can't really utilize the standard login-page to acquire a cookie and all via programmatic access. Instead your API would need to expose some kind of authentication mechanism, that you then would forward to C1 for authorization. It could be a login-method that issues a cookie, or you could require that credentials are included in every request.

But having to send credentials every time you need to do something with the api, or re-authenticate because the cookie has timed out can also be annoying, so implementing some token-based security would be preferred.

Mar 7, 2012 at 12:14 PM

Hi

Yes, SOAP is last century, but I need it for proof-of-concept stuff, not talking about preformance or similar, just
to show it is possible to gain customer's attention and maybe more...

Web API - threw a glimpse, but that is all...

With SOAP WS I can pretty fast integrate on C1 side and there is another point - my client technology has a little
bit problems with other RAD/out-of-the-box stuff (WCF is not fully implemented).

OK. I'll try to digg a bit more and will be back...

 

greetings

mel 

Mar 7, 2012 at 1:44 PM

Web API is pure http and respects the all the different headers and verbs that we're used to from http.

  • It supports Model Binding, meaning that CRUD operations would be very simple to make. As long as you have a model, the framework would make sure to map any incoming post-values into the model as we have become used to in MVC.
  • All normal routing and filters can be used, and when doing querying it supports OData syntax for filtering and paging which is very convenient.
  • Supports content negotiation so a response for a given request can be in any format as you want. Standard formats supported are XML and Json, but its also possible to return binary files.

But it sounds like you have a client with some specific requirement so i guess we're not talking about a 100% generic api here?

Mar 12, 2012 at 8:29 PM

Hi

Regarding Web API et al: the stuff is known to me, but only known - I do understand the concepts, but never did something.
Right now I'd like to:

  • do small academic sample (lab-like)
  • show proof of concept to one of our customers
  • show something to gain attention 

so the decision was that SOAP WS were best shot.

WCF was discussed, but the  technology on the "other side"  has some limitations regarding WCF.

So true the client side has some (at this point in time) limitations or requirements so the API is not (right now) generic...
We are just trying to stay on a stable side.

greetings

mel