Re: Some Slides which contain my Observations and Insights about REST

Hi Thomas,

Regarding
http://vanthome.github.io/rest-api-essay-presentation/rest_apis.html
Very nice material!  And a very nice progression through REST, some 
semantic web concepts, JSON-LD and Hydra.  I really like the line of 
thinking.

A few comments and small suggestions:

  - I would suggest slightly shortening the semantic web section, since 
it introduces several concepts and terms that are not really used 
further in the slides.  This might sound like a strange suggestion 
coming from a semantic web-head like me, :)  but I think one of the nice 
things about JSON-LD is that programmers do not have to be exposed to so 
much semantic web detail when using JSON-LD.

  - If possible, I would suggest adding a small, simple REST example, 
perhaps even showing "DO"s and "DON'T"s.  For example, show what it 
means to have the server return a set of links for the possible client 
next steps, as opposed to having a fixed URL pattern.  Programmers hear 
abstract platitudes REST all the time -- what it is and isn't -- but 
they need to know concretely (through simple examples) how to do REST 
properly.

  - On slide 4, I am slightly uncomfortable with the emphasis on APIs, 
because I fundamentally think we need to get away from the API focus and 
focus on what really matters: THE DATA.  APIs are necessary --  we 
*need* APIs.  But we do *not* need a plethora of different APIs.  We 
should just use REST, be done with that discussion, and move on to the 
more important matter of THE DATA.  (Or, if for some reason someone 
forces you to use something other than REST for a project, then 
gracefully register your disagreement, and move on to the more important 
issue of THE DATA.)  My concern is that if we focus too much on APIs 
then we are likely ignoring what's *really* important, which is THE 
DATA.  I say this in the same spirit as I say that we should not be 
focusing on data formats, we need to focus on the *semantics* of data. 
(Certainly we need data formats, but a data format in and of itself does 
not solve the problem of semantic interoperability.  Data formats allow 
bits to be transferred, but more importantly they should provide a hook 
for determining data semantics, and this is what really matters.)  In 
short, I do not disagree with your statement about the importance of 
offering an API, and I certainly agree that the API of choice is REST, 
but I am just slightly concerned that if we talk too much about APIs we 
may be losing sight of the most important thing: THE DATA.

  - On slide 9 it seems strange to see JavaScript in the same category 
as REST, SOAP and XML-RPC, since JavaScript is a programming language, 
not an API.  I think it would be good to clarify what you mean by 
JavaScript as an API.

  - I was surprised on slide 18 to see:
"Individual resources are identifiable with a GUID".  For REST (and the 
web in general) I think that should be: "Individual resources are 
identifiable with a URI (or IRI)".

  - On slide 15: Where it says "It's not a protocol or about a single 
protocol (HTTP)" I think it would be clearer to say "It's not a 
*transport* protocol or about a single *transport* protocol (HTTP)", 
because in a very broad sense REST *is* a kind of protocol -- it says 
who should do what -- but it isn't a protocol in the sense that I think 
you meant.

  - On Slide 35, a small correction: in RDF 1.1 literals are now 
*always* typed (defaulting to xsd:string).  In Turtle, "foo" and 
"foo"^^xsd:string both have type xsd:string.

  - On slide 40, it would be good to reference the W3C Linked Data Glossary:
http://www.w3.org/TR/ld-glossary/#linked-data

  - You might be interested to look at the paper on "RDF and SOA" that I 
wrote in 2007:
http://dbooth.org/2007/rdf-and-soa/rdf-and-soa-paper.htm
That was written long before JSON-LD existed, when SOA and SOAP were 
still being hyped a lot, and REST was not yet so widely recognized as 
superior (in general) to the WS*/SOA/XML/SOAP approach, but it provides 
a view of how RDF (and now JSON-LD by extension) can be used to great 
advantage in a RESTful or SOA style of interaction.  I think it is very 
much in accordance with the RESTful, JSON-LD-based style that you are 
advocating.

Typos:
s/kicked of/kicked off/
s/syntactucally/syntactically/
s/acomplish/accomplish/
s/What do pseudo REST APIs wrong/What do pseudo REST APIs do wrong/
s/at least on/at least one/
s/tings/things/
s/JSON0-LD/JSON-LD/

Thanks!
David Booth

On 01/14/2015 04:07 AM, Thomas Hoppe wrote:
> Funny :)
> Actually I was really searching hard for this because it bugged me to
> have no reference.
> I remember that I found some stuff but only that within mainframe systems,
> MQ was/ is the dominant integration vehicle and knowing that mainframes
> happened
> before RPC I deduced this.
>
> On 01/14/2015 08:59 AM, Sebastien Lambla wrote:
>> Curioisity item. I was writing a chapter for my book on the same intro you just did. Do you have any reference material for how MQ appareared before RPC?
>>
>>
>>> On 14 Jan 2015, at 07:45, Thomas Hoppe<thomas.hoppe@n-fuse.de>  wrote:
>>>
>>> Hi,
>>>
>>> sorry maybe it's too unrelated for this list but I hope that some of you might find this useful.
>>> I have compiled my (highly opinionated) observations in some slides [1] to give people
>>> (especially with enterprise background) a big picture about what REST is,
>>> why it is relevant and how Hydra and JSON-LD help us making the step to the Web 3.0.
>>>
>>> [1]http://vanthome.github.io/rest-api-essay-presentation/rest_apis.html
>>>
>>> Greets, Thomas
>>>
>>>
>>>
>

Received on Wednesday, 14 January 2015 19:17:25 UTC