7 ms·

Microservices, the Unix Philosophy, and the Richardson Maturity Model

88 points by nkurz 11y ago

joesmo 11y ago
Any microservices discussion that does not take into account both infrastructure complexity and team size is incomplete. For small teams and small/not complex infrastructures, it's always a bad idea. The premium that is paid for switching to microservices is great indeed and it's paid in much slower development and deployment times. This happens as soon as you start breaking an application apart, so even with only a couple of "mini" services, much of the price has been paid. Since the author doesn't mention either, I can't conclude anything, but it's very possible that the team he was advising didn't follow his advice because it was stupid and didn't take into account the above two factors. See obligatory reading: http://martinfowler.com/bliki/MonolithFirst.html http://martinfowler.com/bliki/MonolithFirst.html http://martinfowler.com/bliki/MicroservicePremium.html http://martinfowler.com/bliki/MicroservicePremium.html EDIT: Spacing
- jeffasinger 11y ago
  The cost of being able to efficiently deploy 5 or so services is probably 5x the cost of deploying your single Monolith (this can be a mostly manual process only doable by 1 or 2 people). However the cost of deploying 100 services is still only about 5x the cost of deploying the single Monolith. There's certainly a size threshold below which a microservices approach hurts more than helps.
  - elliotec 11y ago
    How do you figure that deploying 5 services vs 100 is the same cost? Also how do you take into account maintenance and configuration of each individual service and tying them together as a whole? From my experience, even at large enterprise scale, microservices have been a hinderance at the very least when compared to entrenched monoliths. The effort to keep all the individual pieces working properly and harmoniously has never been worth it in any situation I've personally been in.
    - julian_1 11y ago
      > How do you figure that deploying 5 services vs 100 is the same cost? By using generalizable deployment configuration tools - ansible, chef puppet perhaps?. The configuration complexity would probably depend a lot on what exactly those services do. For example - if they are all tomcat containers - with standard integration endpoints then there would be diminishing cost associated with each additional node/service deployment.
      - chrstphrhrt 11y ago
        Relevant: here's a reply I made to a similar question on the original post: https://medium.com/@chrstphrhrt/thanks-1b19b2e3ec09#.g493c33u7 https://medium.com/@chrstphrhrt/thanks-1b19b2e3ec09#.g493c33...
  - joesmo 11y ago
    Maybe, but the increased development costs are incredibly high as soon as you move from a monolith, so much so that the deployment costs, no matter how large, will be dwarfed. For example, in my current setup, having a "mini" services architecture (typical monolith split up into three parts + supporting services) is probably costing us about 25% of our time. In other words, if we had a monolith, we'd be able to spend 3 extra months a year developing or refactoring that are now wasted in the slow development process that is caused slowly by the boundaries between applications.
    - nickpsecurity 11y ago
      You sure it's not the mainstream tools supporting microservices that are the problem? The E language, Fabric secure middleware, and even embedded on OKL4 with Camkes were straight forward. Small teams supported stuff like that because tools do almost all the work. It's like a modular, monolithic app with some parameters to tune and fault isolation. Just seems like development, deployment, and support tooling could knock out issues people describe easily.
    - ktRolster 11y ago
      > having a "mini" services architecture > is probably costing us about 25% of our time. Wow, that's actually quit a bit. What would you estimate is taking most of that time?
    - mej10 11y ago
      How is having microservices vs monolith increasing your development time? We have a lot of microservices, and I feel like having each piece of functionality silo'd with proper service boundaries only speeds up development.
      - mvc 11y ago
        Do you work on more than one in a given week? How do you test a feature which requires co-ordination between several of your services?
      - joesmo 11y ago
  - Florin_Andrei 11y ago
    > The cost of being able to efficiently deploy 5 or so services is probably 5x the cost of deploying your single Monolith I don't know. As soon as you have reasonable Ansible templates for everything, it doesn't matter that much that you're deploying 1, 2, 5, or 50 services.
- chrstphrhrt 11y ago
  Author here, the project I was referring to is a massive unwieldy Scala project using the Play framework (nothing inherently wrong with those choices). It has 177k LOC. It is a matter of months old. It is complete spaghetti and it's impossible to find what does what without learning IDE tricks. Guess I could have mentioned that. So actually my experience confirms the observations of Fowler about breaking up existing things rather than starting out with bunch of different services because fads. That said, I would still start breaking up services that are orthogonal to one another in the same way as one might break up db tables. Iff the interface for writing new services is comprised entirely of a spec for endpoints and their corresponding data schemas. If instead you're thinking of how risky it would be to have a handful of separate services all with their own pile of fragmenting boilerplate to maintain, then yeah, I'd agree a monolith is better still if that's the only option.
  - ktRolster 11y ago
    The writing style of the article was very dense. I would have liked it if you could have condensed out the the sogginess so the main points came through more clearly.
  - pjmlp 11y ago
    Speaking from my own experience, if the team is not able to properly design modular software using the programming language features to write well defined APIs, hiding packages/modules/whatever behind RPC call isn't going to turn them into good API designers anyway. Plus now they need to be good at distributed computing as well.
  - twic 11y ago
    Could you expand on what "IDE tricks" you found necessary? They sound like something I need up my sleeve!
- qyv 11y ago
  The part I love about microservices, and something that I think doesn't get enough attention, is that is strongly enforces separation of concerns across micro-projects. API boundaries are very clear and very rigid, it takes very little effort or oversight to prevent leaking across them. Essentially, you are moving some of the software 'best-practices' up a level form modules to applications themselves. This means that you don't need to spend a lot of effort writing great, best-practices following, future-proof, software upfront for fear of collecting horrible technical debt down the road. Got a service that was rushed out the door and isn't maintainable anymore? Rewrite it! 2 weeks later you have erased a bunch of technical debt and since you kept the same API(s) in place, you have not affected the rest of the services that make up your application. And that is the other thing that I think microservices are great at: They are pragmatically easier to change. Delving into a huge, old, debt-riddled monolithic codebase to make changes is hard and scary, and developers are less likely to want to make changes to monoliths because of that. Microservices are easy to understand because they are small, discrete systems with well understood interface contracts. Making changes to them without breaking the entire app is not scary because it is easier to throughly understand the implications of what is being changed.
  - elliotlarson 11y ago
    I'm sort of playing devil's advocate here, but: > Got a service that was rushed out the door and isn't maintainable anymore? Rewrite it! 2 weeks later you have erased a bunch of technical debt and since you kept the same API(s) in place, you have not affected the rest of the services that make up your application. But that's also true of a monolith. Got a piece of your system that isn't maintainable any more. Rewrite it! 2 weeks later you have erased... you get the point. I like the idea of microservices. I like the idea of the clean boundaries. As a developer, the separation seems correct to me. But, unless you're actually feeling the pain point of the monolith, it just seems like more work that falls into the category of YAGNI. You also said this: > Delving into a huge, old, debt-riddled monolithic codebase to make changes is hard and scary... I mean, it's hard and scary if you don't have a high level of test coverage. If you have great coverage in the old monolith, you should be able to change pieces of it with confidence, no?
- pnathan 11y ago
  Don't forget.... - debugging - networking - service discovery - distributed system fallacy list I've become persuaded that generally microservices are an antipattern largely related to weak technical leadership. They bring incredible weight onto an organization, both technically and socially.
  - aikah 11y ago
    - latency - eventual consistency of data - ...
fmstephe 11y ago
Can anyone add practical experience with the API spec tools. This is a new name for me. I had a look at the websites for each of the three tools the article specifically mentions http://raml.org/ http://swagger.io/ https://apiblueprint.org/ I get the impression that these are code generating tools built from a specification file. I have real world experience with two tools which fit that rough description. SOAP and google app-engine end-points. I would unambiguously describe both as awful. Really horrible experiences with both. They tie your systems to large, and difficult to understand tool sets. SOAP wasn't obviously buggy, but app engine endpoints are unpredictable and the generated code produces some serious awkwardness. I don't want to slap a label on these tools and dismiss them off-hand. Anyone used them 'for the win'?
- wing328hk 11y ago
  https://github.com/swagger-api/swagger-codegen#companiesprojects-using-swagger-codegen https://github.com/swagger-api/swagger-codegen#companiesproj... shows some companies using OpenAPI/Swagger and Swagger Codegen "for the win" - automatically generate API client and server stub given an OpenAPI/Swagger spec. (We obtained permission from these companies to list them in the page) Disclaimer: top contributor to Swagger Codegen
- gypsydave5 11y ago
  Forgive my ignorance, but could someone explain how the tools mentioned above differ from things like: https://msdn.microsoft.com/en-us/library/ff657795.aspx https://msdn.microsoft.com/en-us/library/ff657795.aspx Which I'd taken to be A BAD IDEA: http://programmers.stackexchange.com/questions/124996/is-code-commonly-generated-from-uml http://programmers.stackexchange.com/questions/124996/is-cod...
  - abraae 11y ago
    RAML and the others have a lot of value simply as the source of truth for your API definitions. You need to hold that somewhere - and probably share it with others - and a DSL specifically designed for documenting APIs is a good place. Where else would you hold it after all? However, as developers we love to reach for the stars, so surely that's not enough? Surely we should be able to generate complete, working systems from the RAML (or whatever)! I would say that's a pipe-dream, just as it always has been, and just as it always will be. You might be able to generate a few stubs from RAML (or a UML diagram), but annoyingly, those are also the easiest things for a developer to just crank out anyway, and you'll be up to your ears in compiler soon enough.
vemv 11y ago
Becoming encumbered by a monolithic centralized API that is at risk of reaching its maximum performance and hosting limits. Comically wrong. You can just fire up more instances (aka horizontal scaling). Microservices have their merits, but they're often the (misguided) Dev answer to Ops problems.
- Florin_Andrei 11y ago
  > You can just fire up more instances (aka horizontal scaling). (sigh) I wish that were always doable.
  - vemv 11y ago
    Obviously no technology will give you infinite horizontal scaling for any sufficiently complex app. There is more than one way to achieve scalability. Microservices is just one of the possible choices. It annoys me that developers increasingly see it as the only one.
    - dllthomas 11y ago
      There is more than one way to achieve scalability, but as far as I'm aware all of them beyond something more beyond just firing up more instances.
      - vemv 11y ago
        Designing an infrastructure which allows you to solve problems by firing up more instances is non-trivial work, beyond the skillset of many (otherwise apt) developers.
        dllthomas 11y ago
        I'm not sure I disagree; but that seems to precisely refute your initial, bold claim in this thread.
        11y ago
jessaustin 11y ago
I like stuff like TFA that pulls in concepts from numerous sources even if all the pieces don't fit together perfectly. For instance, I doubt Leonard Richardson would be thrilled with the "Ramses Maturity Model" (we couldn't even coin a different initialism?) and the "Level 2.5" idea. Eschewing links runs counter to Richardson's (and Fielding's) vision, period. If one must know the form of representations ahead of time, one cannot consume them in a completely maintainable way. One wouldn't notice this within the organization, but rather at the edges where it must work with other organizations. That said, Ramses and what it's described as doing is impressive.
- chrstphrhrt 11y ago
  Thanks for the great feedback, you're completely right. I have switched up the language a bit. Regarding hypermedia: I really, really want to work with someone to add first class support for it. I don't think spec is a replacement but rather a compliment to hypermedia. The difference in benefit seeming to be static vs. dynamic client generation and I fully agree that dynamic ought to be the future. Right now static is easy to implement and still quite powerful despite requiring tradeoffs about things like needing to version releases of client libs rather than them being more durable in the dynamic scenario.
mavelikara 11y ago
OT: More than 10 years ago, Jim Waldo [1] gave a great talk on SOA. I remember listening to an MP3 version of it then. I could find many references to the talk online now (eg [2]), but talk itself seems to have vanished off the web. Does anyone have the MP3 of the talk? [1]: http://www.eecs.harvard.edu/~waldo/ http://www.eecs.harvard.edu/~waldo/ . Also see a great paper he co-authored at http://www.eecs.harvard.edu/~waldo/Readings/waldo-94.pdf http://www.eecs.harvard.edu/~waldo/Readings/waldo-94.pdf [2]: http://www.gettingagile.com/2005/09/17/jim-waldos-talk-on-soa/ http://www.gettingagile.com/2005/09/17/jim-waldos-talk-on-so...
- mavelikara 11y ago
  Here are the slides: https://web.archive.org/web/20051029050650/http://www.jini.org/events/0505NYSIG/WaldoNYCJUG.pdf https://web.archive.org/web/20051029050650/http://www.jini.o...
gioele 11y ago
> Then there’s Level 3. It adds hypermedia links to the mix so that clients can dynamically browse resources à la HTML in a browser. This is where Ramses departs from all the awesome work that’s being done in the world of hypermedia. This is the good ol' HATEOAS principle of REST: http://stackoverflow.com/a/9194545/449288 http://stackoverflow.com/a/9194545/449288

88 points by nkurz 11y ago

Any microservices discussion that does not take into account both infrastructure complexity and team size is incomplete. For small teams and small/not complex infrastructures, it's always a bad idea. The premium that is paid for switching to microservices is great indeed and it's paid in much slower development and deployment times. This happens as soon as you start breaking an application apart, so even with only a couple of "mini" services, much of the price has been paid. Since the author doesn't mention either, I can't conclude anything, but it's very possible that the team he was advising didn't follow his advice because it was stupid and didn't take into account the above two factors. See obligatory reading: http://martinfowler.com/bliki/MonolithFirst.html http://martinfowler.com/bliki/MonolithFirst.html http://martinfowler.com/bliki/MicroservicePremium.html http://martinfowler.com/bliki/MicroservicePremium.html EDIT: Spacing

jeffasinger 11y ago
The cost of being able to efficiently deploy 5 or so services is probably 5x the cost of deploying your single Monolith (this can be a mostly manual process only doable by 1 or 2 people). However the cost of deploying 100 services is still only about 5x the cost of deploying the single Monolith. There's certainly a size threshold below which a microservices approach hurts more than helps.
- elliotec 11y ago
  How do you figure that deploying 5 services vs 100 is the same cost? Also how do you take into account maintenance and configuration of each individual service and tying them together as a whole? From my experience, even at large enterprise scale, microservices have been a hinderance at the very least when compared to entrenched monoliths. The effort to keep all the individual pieces working properly and harmoniously has never been worth it in any situation I've personally been in.
  - julian_1 11y ago
    > How do you figure that deploying 5 services vs 100 is the same cost? By using generalizable deployment configuration tools - ansible, chef puppet perhaps?. The configuration complexity would probably depend a lot on what exactly those services do. For example - if they are all tomcat containers - with standard integration endpoints then there would be diminishing cost associated with each additional node/service deployment.
    - chrstphrhrt 11y ago
      Relevant: here's a reply I made to a similar question on the original post: https://medium.com/@chrstphrhrt/thanks-1b19b2e3ec09#.g493c33u7 https://medium.com/@chrstphrhrt/thanks-1b19b2e3ec09#.g493c33...
- joesmo 11y ago
  Maybe, but the increased development costs are incredibly high as soon as you move from a monolith, so much so that the deployment costs, no matter how large, will be dwarfed. For example, in my current setup, having a "mini" services architecture (typical monolith split up into three parts + supporting services) is probably costing us about 25% of our time. In other words, if we had a monolith, we'd be able to spend 3 extra months a year developing or refactoring that are now wasted in the slow development process that is caused slowly by the boundaries between applications.
  - nickpsecurity 11y ago
    You sure it's not the mainstream tools supporting microservices that are the problem? The E language, Fabric secure middleware, and even embedded on OKL4 with Camkes were straight forward. Small teams supported stuff like that because tools do almost all the work. It's like a modular, monolithic app with some parameters to tune and fault isolation. Just seems like development, deployment, and support tooling could knock out issues people describe easily.
  - ktRolster 11y ago
    > having a "mini" services architecture > is probably costing us about 25% of our time. Wow, that's actually quit a bit. What would you estimate is taking most of that time?
  - mej10 11y ago
    How is having microservices vs monolith increasing your development time? We have a lot of microservices, and I feel like having each piece of functionality silo'd with proper service boundaries only speeds up development.
    - mvc 11y ago
      Do you work on more than one in a given week? How do you test a feature which requires co-ordination between several of your services?
    - joesmo 11y ago
- Florin_Andrei 11y ago
  > The cost of being able to efficiently deploy 5 or so services is probably 5x the cost of deploying your single Monolith I don't know. As soon as you have reasonable Ansible templates for everything, it doesn't matter that much that you're deploying 1, 2, 5, or 50 services.
chrstphrhrt 11y ago
Author here, the project I was referring to is a massive unwieldy Scala project using the Play framework (nothing inherently wrong with those choices). It has 177k LOC. It is a matter of months old. It is complete spaghetti and it's impossible to find what does what without learning IDE tricks. Guess I could have mentioned that. So actually my experience confirms the observations of Fowler about breaking up existing things rather than starting out with bunch of different services because fads. That said, I would still start breaking up services that are orthogonal to one another in the same way as one might break up db tables. Iff the interface for writing new services is comprised entirely of a spec for endpoints and their corresponding data schemas. If instead you're thinking of how risky it would be to have a handful of separate services all with their own pile of fragmenting boilerplate to maintain, then yeah, I'd agree a monolith is better still if that's the only option.
- ktRolster 11y ago
  The writing style of the article was very dense. I would have liked it if you could have condensed out the the sogginess so the main points came through more clearly.
- pjmlp 11y ago
  Speaking from my own experience, if the team is not able to properly design modular software using the programming language features to write well defined APIs, hiding packages/modules/whatever behind RPC call isn't going to turn them into good API designers anyway. Plus now they need to be good at distributed computing as well.
- twic 11y ago
  Could you expand on what "IDE tricks" you found necessary? They sound like something I need up my sleeve!
qyv 11y ago
The part I love about microservices, and something that I think doesn't get enough attention, is that is strongly enforces separation of concerns across micro-projects. API boundaries are very clear and very rigid, it takes very little effort or oversight to prevent leaking across them. Essentially, you are moving some of the software 'best-practices' up a level form modules to applications themselves. This means that you don't need to spend a lot of effort writing great, best-practices following, future-proof, software upfront for fear of collecting horrible technical debt down the road. Got a service that was rushed out the door and isn't maintainable anymore? Rewrite it! 2 weeks later you have erased a bunch of technical debt and since you kept the same API(s) in place, you have not affected the rest of the services that make up your application. And that is the other thing that I think microservices are great at: They are pragmatically easier to change. Delving into a huge, old, debt-riddled monolithic codebase to make changes is hard and scary, and developers are less likely to want to make changes to monoliths because of that. Microservices are easy to understand because they are small, discrete systems with well understood interface contracts. Making changes to them without breaking the entire app is not scary because it is easier to throughly understand the implications of what is being changed.
- elliotlarson 11y ago
  I'm sort of playing devil's advocate here, but: > Got a service that was rushed out the door and isn't maintainable anymore? Rewrite it! 2 weeks later you have erased a bunch of technical debt and since you kept the same API(s) in place, you have not affected the rest of the services that make up your application. But that's also true of a monolith. Got a piece of your system that isn't maintainable any more. Rewrite it! 2 weeks later you have erased... you get the point. I like the idea of microservices. I like the idea of the clean boundaries. As a developer, the separation seems correct to me. But, unless you're actually feeling the pain point of the monolith, it just seems like more work that falls into the category of YAGNI. You also said this: > Delving into a huge, old, debt-riddled monolithic codebase to make changes is hard and scary... I mean, it's hard and scary if you don't have a high level of test coverage. If you have great coverage in the old monolith, you should be able to change pieces of it with confidence, no?
pnathan 11y ago
Don't forget.... - debugging - networking - service discovery - distributed system fallacy list I've become persuaded that generally microservices are an antipattern largely related to weak technical leadership. They bring incredible weight onto an organization, both technically and socially.
- aikah 11y ago
  - latency - eventual consistency of data - ...

fmstephe 11y ago

Can anyone add practical experience with the API spec tools. This is a new name for me. I had a look at the websites for each of the three tools the article specifically mentions http://raml.org/ http://swagger.io/ https://apiblueprint.org/ I get the impression that these are code generating tools built from a specification file. I have real world experience with two tools which fit that rough description. SOAP and google app-engine end-points. I would unambiguously describe both as awful. Really horrible experiences with both. They tie your systems to large, and difficult to understand tool sets. SOAP wasn't obviously buggy, but app engine endpoints are unpredictable and the generated code produces some serious awkwardness. I don't want to slap a label on these tools and dismiss them off-hand. Anyone used them 'for the win'?

wing328hk 11y ago
https://github.com/swagger-api/swagger-codegen#companiesprojects-using-swagger-codegen https://github.com/swagger-api/swagger-codegen#companiesproj... shows some companies using OpenAPI/Swagger and Swagger Codegen "for the win" - automatically generate API client and server stub given an OpenAPI/Swagger spec. (We obtained permission from these companies to list them in the page) Disclaimer: top contributor to Swagger Codegen
gypsydave5 11y ago
Forgive my ignorance, but could someone explain how the tools mentioned above differ from things like: https://msdn.microsoft.com/en-us/library/ff657795.aspx https://msdn.microsoft.com/en-us/library/ff657795.aspx Which I'd taken to be A BAD IDEA: http://programmers.stackexchange.com/questions/124996/is-code-commonly-generated-from-uml http://programmers.stackexchange.com/questions/124996/is-cod...
- abraae 11y ago
  RAML and the others have a lot of value simply as the source of truth for your API definitions. You need to hold that somewhere - and probably share it with others - and a DSL specifically designed for documenting APIs is a good place. Where else would you hold it after all? However, as developers we love to reach for the stars, so surely that's not enough? Surely we should be able to generate complete, working systems from the RAML (or whatever)! I would say that's a pipe-dream, just as it always has been, and just as it always will be. You might be able to generate a few stubs from RAML (or a UML diagram), but annoyingly, those are also the easiest things for a developer to just crank out anyway, and you'll be up to your ears in compiler soon enough.

vemv 11y ago

Becoming encumbered by a monolithic centralized API that is at risk of reaching its maximum performance and hosting limits. Comically wrong. You can just fire up more instances (aka horizontal scaling). Microservices have their merits, but they're often the (misguided) Dev answer to Ops problems.

Florin_Andrei 11y ago
> You can just fire up more instances (aka horizontal scaling). (sigh) I wish that were always doable.
- vemv 11y ago
  Obviously no technology will give you infinite horizontal scaling for any sufficiently complex app. There is more than one way to achieve scalability. Microservices is just one of the possible choices. It annoys me that developers increasingly see it as the only one.
  - dllthomas 11y ago
    There is more than one way to achieve scalability, but as far as I'm aware all of them beyond something more beyond just firing up more instances.
    - vemv 11y ago
      Designing an infrastructure which allows you to solve problems by firing up more instances is non-trivial work, beyond the skillset of many (otherwise apt) developers.
      - dllthomas 11y ago
        I'm not sure I disagree; but that seems to precisely refute your initial, bold claim in this thread.
        11y ago

jessaustin 11y ago

I like stuff like TFA that pulls in concepts from numerous sources even if all the pieces don't fit together perfectly. For instance, I doubt Leonard Richardson would be thrilled with the "Ramses Maturity Model" (we couldn't even coin a different initialism?) and the "Level 2.5" idea. Eschewing links runs counter to Richardson's (and Fielding's) vision, period. If one must know the form of representations ahead of time, one cannot consume them in a completely maintainable way. One wouldn't notice this within the organization, but rather at the edges where it must work with other organizations. That said, Ramses and what it's described as doing is impressive.

chrstphrhrt 11y ago
Thanks for the great feedback, you're completely right. I have switched up the language a bit. Regarding hypermedia: I really, really want to work with someone to add first class support for it. I don't think spec is a replacement but rather a compliment to hypermedia. The difference in benefit seeming to be static vs. dynamic client generation and I fully agree that dynamic ought to be the future. Right now static is easy to implement and still quite powerful despite requiring tradeoffs about things like needing to version releases of client libs rather than them being more durable in the dynamic scenario.

mavelikara 11y ago

OT: More than 10 years ago, Jim Waldo [1] gave a great talk on SOA. I remember listening to an MP3 version of it then. I could find many references to the talk online now (eg [2]), but talk itself seems to have vanished off the web. Does anyone have the MP3 of the talk? [1]: http://www.eecs.harvard.edu/~waldo/ http://www.eecs.harvard.edu/~waldo/ . Also see a great paper he co-authored at http://www.eecs.harvard.edu/~waldo/Readings/waldo-94.pdf http://www.eecs.harvard.edu/~waldo/Readings/waldo-94.pdf [2]: http://www.gettingagile.com/2005/09/17/jim-waldos-talk-on-soa/ http://www.gettingagile.com/2005/09/17/jim-waldos-talk-on-so...

mavelikara 11y ago
Here are the slides: https://web.archive.org/web/20051029050650/http://www.jini.org/events/0505NYSIG/WaldoNYCJUG.pdf https://web.archive.org/web/20051029050650/http://www.jini.o...

gioele 11y ago

> Then there’s Level 3. It adds hypermedia links to the mix so that clients can dynamically browse resources à la HTML in a browser. This is where Ramses departs from all the awesome work that’s being done in the world of hypermedia. This is the good ol' HATEOAS principle of REST: http://stackoverflow.com/a/9194545/449288 http://stackoverflow.com/a/9194545/449288