Showing posts with label http. Show all posts
Showing posts with label http. Show all posts

Sunday, 22 May 2016

The InfoQ Podcast: Uber's Chief Systems Architect = No Node.js, no JSON over HTTP

The InfoQ Podcast: Uber's Chief Systems Architect on their Architecture and Rapid Growth: "In this week's podcast QCon chair Wesley Reisz talks to Matt Ranney who is the Chief Systems Architect at Uber, where he's helping build and scale everything he can. Previously, Matt was a founder and CTO of Voxer, probably the largest and busiest deployment of Node.js.

Key takeaways

Expanding a company and team at this rate is genuinely hard. Lots of mistakes have been made along the way.
Microservices allow companies to grow rapidly but have a cost in terms of aggregate velocity.
Uber is gradually moving its marketplace development from Node.js to Go and Java. Java is used for the map services.
Aggressive failure testing is used extensively in Uber.
Some early design choices - like using JSON over HTTP - make formal verification basically impossible."



'via Blog this'

Monday, 16 May 2016

Overcoming Swagger Annotation Overload by Switching to JSON - DZone Integration

Overcoming Swagger Annotation Overload by Switching to JSON - DZone Integration: "Despite taking the "Build First" approach, we were able to revert to a "Design First"-like state relatively painlessly. The resulting (largely) annotation-free code was much easier on the eyes and the single definition file worked much better for documentation purposes. Perhaps in the future, I'll build an API with a design more suited for Swagger annotations or use a true design first approach. But for this particular API, changing course was the right call."



'via Blog this'

Friday, 13 May 2016

Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it

https://blog.teller.io/



"One of the biggest problems with OAuth 2.0 is that it delegates all security concerns to TLS but only the client authenticates the server (via it's SSL certificate), the server does not authenticate the client. This means the server has no way of knowing who is actually sending the request. Is it a bona fide user, or is an attacker tampering with the request? When an attacker is able to insinuate themselves between a legitimate user and the server, it's called a man-in-the-middle (MITM) attack. 



It looks like this:

client attempts to connect to service
attacker successfully reroutes traffic to a host it controls
malicious host accepts connection from client
malicious host connects to service
service accepts connection from malicious host
client communicates with service proxied through malicious host, which can see and tamper with any data sent or received 



You're probably thinking "hang on, isn't this the point of SSL?" Yes it is, but there are a number of ways to present a bogus certificate and a client accept it. The most realistic threat is the client developer not properly verifying the server certificate, i.e. was it ultimately signed by a trusted certificate authority?

Unfortunately a large number of developers think that disabling SSL peer verification is the correct fix to a SSL path validation error. There are many more that will offer the same advice with the caveat that it introduces a security issue that < 100% of readers will consider. As an API provider with a duty of care to our users we can't simply hope developers on our platform don't do this."




'via Blog this'

Saturday, 9 April 2016

WebPagetest - Website Performance and Optimization Test

WebPagetest - Website Performance and Optimization Test: "Run a free website speed test from multiple locations around the globe using real browsers (IE and Chrome) and at real consumer connection speeds. You can run simple tests or perform advanced testing including multi-step transactions, video capture, content blocking and much more. Your results will provide rich diagnostic information including resource loading waterfall charts, Page Speed optimization checks and suggestions for improvements."



'via Blog this'

Thursday, 16 April 2015

Visualisation, HTML5, UX and HTTP links

modeling-languages.com: 10 JavaScript libraries to draw your own diagrams

Comparative table of JavaScript drawing libraries

To finish here is a basic comparative table between the presented libraries.
LibraryLicenseLanguage / infrastructurehigh/low levelbuilt-in editorGithub (04/02/2015)
JointJSMPLHTML
Javascript
SVG
highNo1388 stars
265 forks
RappidCommercial
1 500,00 €
HTML
Javascript
SVG
highYes
MxgraphCommercial
4300.00 €
HTML
Javascript
SVG
highYes
GoJSCommercial
$1,350.00
HTML
Canvas
Javascript
HighYes
RaphaelMITHTML
Javascript
SVG
lowNo7105 stars
1078 forks
Draw2DGPL2
commercial
HTML
Javascript
SVG
mediumNo
D3BSDHTML
Javascript
SVG
lowNo36218 stars
9142 forks
FabricJSMITHTML
Canvas
javasript
lowNo4127 stars
705 forks
paperJSMITHTML
Canvas
javascript
lowNo4887 stars
496 forks
JsPlumbMIT/GPL2HTML
Javascript
mediumNo2161 stars
563 forks