11–20 of 38 posts
Disclaimer: I do not want to steal the author's page views, but I could hardly read this article, due to the white shadow in the Text. Here is a more readable view: http://rdit.in/5c
In Chrome I do right-click, inspect element. Then I CSS the shadow away :)
What is the HATEOS compliant way of accepting parameters? E.g. for the pagination example, you might want to let the consumer specify number of entries pr. page, or you might want to accept a search-term or limit by period.
However, getting a client to automatically understand this is a little harder.
You could approximate a form in JSON, which would be similar in structure to its HTML counterpart.
What is the HATEOS compliant way of accepting parameters? E.g. for the pagination example, you might want to let the consumer specify number of entries pr. page, or you might want to accept a search-term or limit by period.
What is the HATEOS compliant way of accepting parameters? E.g. for the pagination example, you might want to let the consumer specify number of entries pr. page, or you might want to accept a search-term or limit by period.
An HTML form could be one way of doing this. As long as the API complies with the form it sends out. However, getting a client to automatically understand this is a little harder. You could approximate a form in JSON, which would be similar in structure to its HTML counterpart.
What is the HATEOS compliant way of accepting parameters? E.g. for the pagination example, you might want to let the consumer specify number of entries pr. page, or you might want to accept a search-term or limit by period.
So
href="foo/bar/?baz=x"
For instance, if there are 10 pages then x ranges over [1-10]. If the client request ?page = 11 then we'd return a 405 error indicating that the only valid values are [1-10].
What is the HATEOS compliant way of accepting parameters? E.g. for the pagination example, you might want to let the consumer specify number of entries pr. page, or you might want to accept a search-term or limit by period.
it would accept parameters. I think having a template requires the client to understand a format other than hypertext.
This is probably my number one criticism of most "REST" APIs out there - they are horribly non self-documenting, and the effort required to make them self-documenting is really fairly trivial: 1. Ensure that you have a URI to the resource in question every single time you reference an ID somewhere (in collections, when referencing resources from another resource) 2. Make the root of your application document all the…
I hate when people try tell me REST isnt the way to go. I guess if you're an out-dated organization with a lot of time (and money) on your hands, you could stuff around with something else...but why would you in this world as a startup do anything else? Nice article, i think the world needs a very basic "this is how you use REST" bullet point style blog post somewhere. This lesson would be 1 of those bullet points if…
Because the tech's immature and irrelevant to your core competency? The paragraph at the end of the HATEOAS page sums it up pretty well for me - and seems to be struggling to make the case for the benefits of "full REST". I despise the enterprisey verbosity of SOAP et al, but given the choice between an inefficient but well understood standard with good tooling support and the new hotness that no-one quite understands properly yet...
What is the HATEOS compliant way of accepting parameters? E.g. for the pagination example, you might want to let the consumer specify number of entries pr. page, or you might want to accept a search-term or limit by period.
Query parameters create hyperlink templates. So href="foo/bar/?baz=x" is really a way for generating a set of hyperlinks that range over whatever domain x comes from and the client should feel free to plug in any valid value for x. You can even indicate the domain of x by returning a 405 in the case of an invalid value (although it would be nice to have a standard way of indicating the domain beforehand) For instance…
In your example, I need to know that the x is something that requires replacement. How is that fundamentally different from just putting in your documentation (and, in the 405 if not passed) "this resources takes query param baz" - which is not HATEOS?
Also, this doesn't cover the case of optional parameters. Specifying optionality in a template is horrible (something like "bar/?baz=x[&ogle=y]" to borrow the pattern from man pages), and specifying individual URLs for each combination of parameters is impractical for more than a few.