3 ms·

I so agree with this. I have been complainging in different companies that using REST is not practical between application (at least use JSON-API then). REST is

I so agree with this. I have been complainging in different companies that using REST is not practical between application (at least use JSON-API then). REST is usefull for frontend <-> backend communication. SOAP was horrible simetimes but it worked. If you change the contract the clients simply do not compile. This is not the case when you change a service using REST (yeah there are some fixes for that but they are not common and widely used).

dragonwriter 6y ago
> I have been complainging in different companies that using REST is not practical between application (at least use JSON-API then). JSON-API is REST, though not all REST is JSON-API. > REST is usefull for frontend <-> backend communication. Actual REST is least useful for communication between a single frontend and backend controlled by the same party. > SOAP was horrible simetimes but it worked. More accurately, SOAP was horrible and it sometimes worked. > If you change the contract the clients simply do not compile. I’m not sure how that would be a good thing, even if it were true, which it isn't unless you are fetching the WSDL and then recompiling clients each time you try to access the server. > This is not the case when you change a service using REST Which is a good thing, HATOEAS plus resources described with media types and using content-type and accept headers properly, all of which is part of REST over HTTP, give you plenty of opportunity for clean error for a representation change you can't handle without requiring you to try compiling at each access.
- theSIRius 6y ago
  > Actual REST is least useful for communication between a single frontend and backend controlled by the same party. I know I'm going off-topic but what is best way to communicate between frontend and backend except for REST? I know about GraphQL even though that is not widely adopted yet and in a lot of cases never will be.

dragonwriter 6y ago

> I have been complainging in different companies that using REST is not practical between application (at least use JSON-API then). JSON-API is REST, though not all REST is JSON-API. > REST is usefull for frontend <-> backend communication. Actual REST is least useful for communication between a single frontend and backend controlled by the same party. > SOAP was horrible simetimes but it worked. More accurately, SOAP was horrible and it sometimes worked. > If you change the contract the clients simply do not compile. I’m not sure how that would be a good thing, even if it were true, which it isn't unless you are fetching the WSDL and then recompiling clients each time you try to access the server. > This is not the case when you change a service using REST Which is a good thing, HATOEAS plus resources described with media types and using content-type and accept headers properly, all of which is part of REST over HTTP, give you plenty of opportunity for clean error for a representation change you can't handle without requiring you to try compiling at each access.

theSIRius 6y ago
> Actual REST is least useful for communication between a single frontend and backend controlled by the same party. I know I'm going off-topic but what is best way to communicate between frontend and backend except for REST? I know about GraphQL even though that is not widely adopted yet and in a lot of cases never will be.