4 ms·

I think what bothers me most about REST is that the endpoint is not sufficient to get started. The schema is never known. I hate SOAP and xml-rpc, but at least

by jquast 10y ago

I think what bothers me most about REST is that the endpoint is not sufficient to get started. The schema is never known. I hate SOAP and xml-rpc, but at least you can know for sure what endpoints, parameters, and variable types are appropriate. With REST, you must have documentation or source code of the service you communicate with, they offer no discoverability. I won't use REST again. I got an opportunity to use GraphQL recently in my profession and all of my projects will be using it in the future.

teddyh 10y ago
REST without using hypertext data types is indeed non-discoverable. You have experienced why REST is almost pointless without HATEOAS. Next time, look into using REST with HATEOAS, as it was intended to be used.
- jquast 10y ago
  Previously using HATEOAS, gathering large amounts of data, say some kind of reporting dashboard, required a great deal of seperate HTTP requests, it was far less efficient in I/O and performance than without. Anyway, I find GraphQL provides this solution very kindly, I can ask questions about the great big world, and request only specific fields, like a user's name, the names of their 10 closest friends and their availability status, all in a single call. With HATEOAS this could be 10 to 20 calls, and maybe contain extra information in the response I'm not necessarily interested in.
  - other_herbert 10y ago
    I was looking for someone to mention graphql... For lots of cases this is a great way to reduce the client calls and give the client exactly what it is asking for..
dragonwriter 10y ago
> I think what bothers me most about REST is that the endpoint is not sufficient to get started. The schema is never known. If you are actually doing REST, the interpretation of a resource representation is fully specified by the media-type (insofar as if there is additional schema, etc., information necessary, how to find that given the actual representation is also defined by the media type.) Obviously, this is not true in the all-to-common REST-minus-HATEOAS.
- djsumdog 10y ago
  You can sprinkle links/rel and use custom/vnd mime types (and include links to the correct json or xml schema) and then a developer can figure out how an API works just from an endpoint, yes .. but that's not what this person is saying. The thing about SOAP is that it is very concrete and a standard. Yes you get implementation glitches/bugs here and there, but for the most part, you have a standard definition for an object and a standard way to describe it. It's so standard you can point a debugging tool like SoapUI at it and it will construct a nice little form for filling out all the objects you want to pass with the correct types. There are other terrible things about SOAP and it's difficult to version/add functions/update/blah blah, but it was concrete. You could create tools to auto-discover all the paths in HATEOAS implementations, but it's still not quite as concrete as SOAP. Most people don't and rely on documentation to build clients with the right schema/requests/types. REST/HATEOAS are concepts and you document your formats, marshallers, etc. SOAP/WSDLs describes the entire data-interchange in a much more concrete format. As much as I hate SOAP, I wish we had a more concrete interchange standard that wasn't as terribly complex.
  - elcritch 10y ago
    Swagger is a decent middle ground. There's a lot of warts, but it's serviceable and fairly prevalent with implementations in a variety of languages. Mainly I like to use the yaml version to quickly communicate rest api's. I've also recently started appreciating JSON Schema more recently for this reason. It's lighter weight than xml schemas. Inclusion of regex based field validation is pretty handy.
jasonkostempski 10y ago
"With REST, you must have documentation or source code of the service you communicate with, they offer no discoverability." A simple reusable class library of request and response entities is easy to provide in multiple languages.

by jquast 10y ago

teddyh 10y ago

REST without using hypertext data types is indeed non-discoverable. You have experienced why REST is almost pointless without HATEOAS. Next time, look into using REST with HATEOAS, as it was intended to be used.

jquast 10y ago
Previously using HATEOAS, gathering large amounts of data, say some kind of reporting dashboard, required a great deal of seperate HTTP requests, it was far less efficient in I/O and performance than without. Anyway, I find GraphQL provides this solution very kindly, I can ask questions about the great big world, and request only specific fields, like a user's name, the names of their 10 closest friends and their availability status, all in a single call. With HATEOAS this could be 10 to 20 calls, and maybe contain extra information in the response I'm not necessarily interested in.
- other_herbert 10y ago
  I was looking for someone to mention graphql... For lots of cases this is a great way to reduce the client calls and give the client exactly what it is asking for..

dragonwriter 10y ago

> I think what bothers me most about REST is that the endpoint is not sufficient to get started. The schema is never known. If you are actually doing REST, the interpretation of a resource representation is fully specified by the media-type (insofar as if there is additional schema, etc., information necessary, how to find that given the actual representation is also defined by the media type.) Obviously, this is not true in the all-to-common REST-minus-HATEOAS.

djsumdog 10y ago
You can sprinkle links/rel and use custom/vnd mime types (and include links to the correct json or xml schema) and then a developer can figure out how an API works just from an endpoint, yes .. but that's not what this person is saying. The thing about SOAP is that it is very concrete and a standard. Yes you get implementation glitches/bugs here and there, but for the most part, you have a standard definition for an object and a standard way to describe it. It's so standard you can point a debugging tool like SoapUI at it and it will construct a nice little form for filling out all the objects you want to pass with the correct types. There are other terrible things about SOAP and it's difficult to version/add functions/update/blah blah, but it was concrete. You could create tools to auto-discover all the paths in HATEOAS implementations, but it's still not quite as concrete as SOAP. Most people don't and rely on documentation to build clients with the right schema/requests/types. REST/HATEOAS are concepts and you document your formats, marshallers, etc. SOAP/WSDLs describes the entire data-interchange in a much more concrete format. As much as I hate SOAP, I wish we had a more concrete interchange standard that wasn't as terribly complex.
- elcritch 10y ago
  Swagger is a decent middle ground. There's a lot of warts, but it's serviceable and fairly prevalent with implementations in a variety of languages. Mainly I like to use the yaml version to quickly communicate rest api's. I've also recently started appreciating JSON Schema more recently for this reason. It's lighter weight than xml schemas. Inclusion of regex based field validation is pretty handy.

jasonkostempski 10y ago

"With REST, you must have documentation or source code of the service you communicate with, they offer no discoverability." A simple reusable class library of request and response entities is easy to provide in multiple languages.