3 ms·

Xmlrpc is simple and it works. Xmlrpc is soap without the bullshit. I built lots of personal apps that were flash/flex front ends that talked to python backe

Xmlrpc is simple and it works. Xmlrpc is soap without the bullshit. I built lots of personal apps that were flash/flex front ends that talked to python backends over xmlrpc to quickly whip up his for my python aps

dboreham 9y ago
btw SOAP was supposed to be "xmprpc standardized" I remember well the meeting when things started to go off track...
- goliatone 9y ago
  Im actually curious now that you mention it but don’t expand on it. Was the road to hell really paved with good intentions?
  - dboreham 9y ago
    I don't remember the history prior to the meeting well enough today to give an authoritative version. So for fear of getting some of it wrong I will say nothing. However, I'll say that the answer to your question is "no".
deleted 9y ago
[deleted]
0x445442 9y ago
Having implemented many web service APIs in both SOAP and REST I have the same opinion. XMLRPC or JSONRPC seem to be the happy middle ground. The posted article hit home with me as I had to re-implement working SOAP services in REST because you know, management buzzwords and new shiny. I quickly found, as the article articulates, as soon as you enter the land of verbs and workflows REST starts to stumble and becomes very network chatty. And when that network chattiness is backed by other network chattiness the grumblings of why the hell you can't just return a deep object graph of data from an endpoint ensue.
- 3pt14159 9y ago
  But you can with REST. Most of this conversation is a strawman against REST. Creating or changing resources can impact other resources. It's obvious / logical. Responses can include the things that they impacted along the way. Much of this thread amounts to "I used this shitty REST API once" or similar for RPC.
  - 0x445442 9y ago
    Well, it depends on how you reckon REST. I can assure you the real world issues I've run into don't have anything to do with the frameworks used. The impedance mismatch between what one would consider a sane API that could just as easily be implemented as a compiled library and the mappings of that API to HTTP verbs and what is considered proper REST were where the problems were. My question would be, outside of convenience to SPA developers, what do you see as the specific advantages to REST over XML/JSON RPC or SOAP?
    - 3pt14159 9y ago
      I don’t really remember SOAP since that was over a decade ago, but what I like about REST is that it harmonizes the front end and backend structures of the application and it makes things predictable. It also puts up some guardrails against obviously dumb behaviour like deleting records via a GET and with JSON API, makes it possible for things to snap together once you’ve got the structure right. Ember Data + Rails set up to follow JSON API is just unbelievably productive. Pagination, filtering, optionally including other resources, linking (both to the related resource itself and to the relationship itself) it’s really fast, consistent, powerful, flexible, and secure. It’s not always performant, but when performance is important I make one little RCP or nonstandard REST endpoint (say return a link to a big TSV blob) and I move on with life.
corg890 9y ago
It lacks conventions thoug so every api is more quirky and even sloppier than a bad REST api. At least with REST there’s some existing structure and it’s not completely up to the imagination of someone in a hurry.

dboreham 9y ago

btw SOAP was supposed to be "xmprpc standardized" I remember well the meeting when things started to go off track...

goliatone 9y ago
Im actually curious now that you mention it but don’t expand on it. Was the road to hell really paved with good intentions?
- dboreham 9y ago
  I don't remember the history prior to the meeting well enough today to give an authoritative version. So for fear of getting some of it wrong I will say nothing. However, I'll say that the answer to your question is "no".

deleted 9y ago

[deleted]

0x445442 9y ago

Having implemented many web service APIs in both SOAP and REST I have the same opinion. XMLRPC or JSONRPC seem to be the happy middle ground. The posted article hit home with me as I had to re-implement working SOAP services in REST because you know, management buzzwords and new shiny. I quickly found, as the article articulates, as soon as you enter the land of verbs and workflows REST starts to stumble and becomes very network chatty. And when that network chattiness is backed by other network chattiness the grumblings of why the hell you can't just return a deep object graph of data from an endpoint ensue.

3pt14159 9y ago
But you can with REST. Most of this conversation is a strawman against REST. Creating or changing resources can impact other resources. It's obvious / logical. Responses can include the things that they impacted along the way. Much of this thread amounts to "I used this shitty REST API once" or similar for RPC.
- 0x445442 9y ago
  Well, it depends on how you reckon REST. I can assure you the real world issues I've run into don't have anything to do with the frameworks used. The impedance mismatch between what one would consider a sane API that could just as easily be implemented as a compiled library and the mappings of that API to HTTP verbs and what is considered proper REST were where the problems were. My question would be, outside of convenience to SPA developers, what do you see as the specific advantages to REST over XML/JSON RPC or SOAP?
  - 3pt14159 9y ago
    I don’t really remember SOAP since that was over a decade ago, but what I like about REST is that it harmonizes the front end and backend structures of the application and it makes things predictable. It also puts up some guardrails against obviously dumb behaviour like deleting records via a GET and with JSON API, makes it possible for things to snap together once you’ve got the structure right. Ember Data + Rails set up to follow JSON API is just unbelievably productive. Pagination, filtering, optionally including other resources, linking (both to the related resource itself and to the relationship itself) it’s really fast, consistent, powerful, flexible, and secure. It’s not always performant, but when performance is important I make one little RCP or nonstandard REST endpoint (say return a link to a big TSV blob) and I move on with life.

corg890 9y ago

It lacks conventions thoug so every api is more quirky and even sloppier than a bad REST api. At least with REST there’s some existing structure and it’s not completely up to the imagination of someone in a hurry.