diff options
| author | alex <alex@pdp7.net> | 2023-10-14 16:57:17 +0200 |
|---|---|---|
| committer | alex <alex@pdp7.net> | 2023-10-14 16:57:31 +0200 |
| commit | a79b1b78a565a7b4d12297fc7814b9804c894fea (patch) | |
| tree | 5dd46b1f0c036d11f65fa5995cdf538f2ee8e44b /blog/content/2012/11/que-es-el-rpc.gmi | |
| parent | a459e1e07f925b9ece59190a2d98e4353db0c69a (diff) | |
Add trailing new lines
Diffstat (limited to 'blog/content/2012/11/que-es-el-rpc.gmi')
| -rw-r--r-- | blog/content/2012/11/que-es-el-rpc.gmi | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/blog/content/2012/11/que-es-el-rpc.gmi b/blog/content/2012/11/que-es-el-rpc.gmi index 6aa7fb03..a0a82192 100644 --- a/blog/content/2012/11/que-es-el-rpc.gmi +++ b/blog/content/2012/11/que-es-el-rpc.gmi @@ -40,4 +40,4 @@ Con RPC nos podemos ahorrar mucho código repetitivo de comunicación que supone No, desde luego que no. Aún pueden existir problemas de interoperabilidad entre algunas plataformas poco populares, o los mecanismos de RPC puede que no sean buenos. REST es siempre un mínimo común denominador y la verdadera manera de asegurarnos que nuestros servicios pueden ser utilizados universalmente- incluso yo recomendaría que aunque implementemos RPC, ofrezcamos también REST para quien no pueda utilizarlo (recordemos igualmente que puede ser sencillo exponer un mismo servicio tanto con XML-RPC, como con JSON-RPC simultáneamente sin mucho esfuerzo, ampliando horizontes), y REST sigue siendo útil para exploración y "descubribilidad". -Pero, cuando sea posible y adecuado, ahorrémonos escribir código de más.
\ No newline at end of file +Pero, cuando sea posible y adecuado, ahorrémonos escribir código de más. |
