8.3 - vote for OAuth support for exposed REST services.

[aware_support]

As you probably know Aware IM allows you to expose REST services. However, unlike consumption of REST services, exposed services do not have support for security (OAuth).

It's quite a lot of work to support OAuth for exposed services. Our question to you is how useful would this feature be for you. Please vote yes or no.

[Jaymer]

yes - this will enable me to offer a solution for corporate IT needs

[Jaymer]

FWIW,
here's a Node.js OAuth2.0 server implementation

This would allow Bruce, for example, to expose his client's POs, Ordering, etc. to their customers and vendors.
He would use JS to code, parse, etc. all the requests and post directly to the database (which bypasses any Aware business rules).

Question: If Aware DID NOT have this [security] built into it, what chance would Aware have of being the solution for his client?
or... if Aware doesn't offer the highest level of REST security, they'll do it in another tool.
So, if we [ie. Vlad and team] don't do this now, then how many more future opportunities will be missed by us [developers] and Aware?

(cross posted to the REST Vote thread - unsure where the best place for this is)

[BenHayat]

...

[customaware]

+100

[BenHayat]

...

[BenHayat]

...

[Jaymer]

LOL
30 minutes before you posted this, I wrote Himanshu the following email:

hi
please respond to this thread

https://www.awareim.com/forum/viewtopic ... 46&p=50018

please take time to think about this, and your presentation from the last conference.

how will this help you?
is this a good thing?
are there more opportunities out there BECAUSE higher REST security will be built into aware?
What about more technology on the Aware side to handle incoming JSON msgs.?
We need new commands to parse strings, and send REST response codes.

Do you feel you have just as much opportunity to make REST/mobile solutions using Aware AS IT IS NOW? … even if he does no improvements, will that affect you?

Will be interested to see how he responds, since he's been thru the implementation the Vlad referred to in his OP

[BenHayat]

...

[aware_support]

Code: Select all

With all due respect, the security should be added ONLY if the REST implementation supports true REST standards that any app or system can use Aware REST service as if it was written in Java or Node or .Net and etc.
If it lacks features and we can not truly use it, then the whole OAuth work and resources will be waste of time, because it's not usable.

Sorry, I really have no idea what you are talking about. Why doesn't current Aware IM REST implementation support "true REST standards"? What standards are these?

We certainly have clients who use current implementation irrespective of the "standards".

[BenHayat]

...

[aware_support]

What is this document, Ben? It contains some fragments of some guidelines, which come out of nowhere. Are these the official standards approved by a relevant authority? Is there a formal specification?

By the way, Aware IM already follows whatever recommendations this document has.

From my experience (rather extensive) of working with REST there are no standards. Every vendor (FB, Google, Dropbox etc) seems to do whatever it pleases. And there is not much scope for variation in REST anyway.

[BenHayat]

...

[johntalbott]

There are many REST best practice resources that prescribe the same basic fundamentals.

-HTTP verbs - GET, PUT, POST, DELETE, PATCH
-CORS (Cross-Origin Resource Sharing)
-JSON input
-Standard Response Codes
-Filtering, Sorting, Paging
-OAuth
-API Versioning

REST Best Practices References
https://github.com/Microsoft/api-guidel ... delines.md
https://github.com/tfredrich/RestApiTut ... s-v1_2.pdf
https://www.ibm.com/support/knowledgece ... tions.html

[aware_support]

Code: Select all

There are many REST best practice resources ,,.

These are just best practices. Nothing stops anyone from using current Aware IM REST services.

Let's not digress. This thread is about OAuth support for exposed services - whether you will use it or not.