REST and JSON replace SOAP and XML
Enterprise Software architects (such as e.g. Tom Marrs) say: Due to the rise of JSON Schema, XML has now become legacy.I won't create new XML-based Web Services anymore unless someone absolutely requires it.
Initially, JSON was (and still is) great for Web applications, but due to JSON Schema, JSON is now a first-class player across the enterprise. JSON Schema enables architects and developers to provide a structure for the data exchanged between a Web Service and its consumers. JSON is (as of 2013) the dominant format for Streaming APIs.
JSON is a Javascript friendly data format fitting cleanly with HTML5 mobile applications (JSON-formatted data can be manipulated directly by Javascript — mappings from and to XML are no longer necessary).
JavaScript's rise in popularity is definitely leading to increased JSON usage, but so is the rise of RESTful Web Services. REST and JSON go hand-in-hand because they are made for each other. They're light, easy to use and understand, standards-based, and enterprise-class.
See also:
- REST explained by Roy Fielding himself
- REST RefCard
- REST oft missverstanden
- REST in 2014: siehe Diagramm 1 und dann den ganzen Rest dieses Artikels
- REST API Design and Best Practices, see more
- Tools to create Documentation of REST APIs, e.g. Swagger
- RESTful .NET, see also [1], [2]
- JSON Reference Card
- JSON well implemented: JSoniter's JSON Iterator
- JSON in current DBMS Products
- JSON vs XML — both habe advantages: /m
- JSend
- 3000 out of 5000 major Web API are already REST, more ...
- REST Reference Implementation
- Restlet
- HateOAS: The HATEOAS constraint decouples client and server in a way that allows the server functionality to evolve independently.
- Learn REST in combination with PHP or some other specific language ...
- Creating a REST Web Service
- Dropwizard — a nice Open Source REST Application Server
- The RESTful Cookbook
- Example: Camunda's REST-API
There is only one aspect of this example that could be solved better: The data should identify itself with respect to the chosen format (so that we are free to choose either JSON or some other format).
See also current Trend Reports: REST vs SOAP — XML vs JSON — Beyond JSON — EAI 2014
Schönes Beispiel für ein REST und JSON nutzendes Web API ist Microsofts Service Management API zu Azure. Es zeigt recht deutlich, dass eine JSON File eigentlich nur eine eingerückte Liste ist. Noch einfacher geht es nun wirklich nicht.
Source: 3SCALE explaining Business APIs (2014)
Single Page Applications (Apps) lassen sich grob wie folgt charakterisieren (zitiert aus Osmanis Buch Developing Backbone.js Applications):
Not so long ago, the term » data-rich web application « was an oxymoron. Today, these applications are everywhere and you need to know how to build them.
Traditionally, web applications left the heavy-lifting of data to servers that pushed HTML to the browser in complete page loads. The use of client-side JavaScript was limited to improving the user experience. Now this relationship has been inverted – client applications pull raw data from the server and render it into the browser when and where it is needed.
Think of the Ajax shopping cart which doesn’t require a refresh on the page when adding an item to your basket. Initially, jQuery became the go-to library for this paradigm. Its nature was to make Ajax requests then update text on the page and so on. However, this pattern with jQuery revealed that we have implicit model data on the client side. With the server no longer being the only place that knows about our item count, it was a hint that there was a natural tension and pull of this evolution.
The rise of arbitrary code on the client-side which can talk to the server however it sees fit has meant an increase in client-side complexity. Good architecture on the client has gone from an afterthought to essential – you can’t just hack together some jQuery code and expect it to scale as your application grows. Most likely, you would end up with a nightmarish tangle of UI callbacks entwined with business logic, destined to be discarded by the poor soul who inherits your code.
Thankfully, there are a growing number of JavaScript libraries that can help improve the structure and maintainability of your code, making it easier to build ambitious interfaces without a great deal of effort. Backbone.js has quickly become one of the most popular open-source solutions to address these issues ...
Warum aber geschieht heute, was lange Zeit verpönt war (nämlich neben Code für die Präsentation von Daten auch Code für deren Verarbeitung, für die Geschäftslogik also, in den Client zu legen)? Der Grund hierfür ist einfach:
auch Schnittstelle zwischen G e s c h ä f t s p a r t n e r n sein können.
Damit die dann aber auch stets aktuelle, ausreichend detaillierte und über alle Unternehmen hinweg einheitlich gestaltete Dokumentation der REST APIs vorfinden, sollte man sie unbedingt per RAML beschreiben und daraus dann HTML generieren. Wie so ein REST API dann durch Benutzer verstehbar wird, zeigt sehr schön ein Beispiel (die farbigen Buttons führen zu ausreichend genauer Dokumentation wirklich aller formalen Details der entsprechenden Funktionen).
Und natürlich kann im Anschluss an die formalen Details — wo notwendig oder hilfreich — auch jede Menge anwendungstechnischer Semantik von Funktion und Daten erklärt sein.
Read also:
- JSON RPC — fast and simple
- OAuth 2.0 — the latest authentiaction protocol
- REST in PHP
stw3434JSONRESTAPI — JSON . REST . API — News?
Mehr + B G E + S H A + More