Databases
StackOverflow2013
Postsdbo
POREST api versioning (only version the representation, not the resource itself)
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POREST api versioning (only version the representation, not the resource itself)
    primarykey
    data
    text
    <p>I had a look at <a href="https://stackoverflow.com/questions/389169/best-practices-for-api-versioning">Best practices for API versioning?</a>, but am not quite convinced of the answer, so I am question the versioning part again with a more specific example. I am having two URIs (one with versioning as part of the URI and one without):</p> <pre><code>http://xxxx/v1/user/123 -&gt; favored solution in discussed thread http://xxxx/user/123 </code></pre> <p>I am having my doubts whether the first link expresses the idea of REST. I find <code>http://xxxx/v1/user/123</code> confusing as it suggests that there will be a higher api-version someday like <code>http://xxxx/v2/user/123</code>. But this does not make sense in REST terms, the api version itself is HTTP 1.0 or 1.1, which is already sent inside the HTTP request. This REST resource centric view differs very from other api-interfaces like SOAP or Java-interfaces (where it is common to have api-versions in qualified names).</p> <p>At REST the only thing where versioning makes sense is the representation of that resource (e.g. new fields are added or removed). This versioning belongs to the part of content-negotiation like:</p> <pre><code>http://xxx/user/123 + HTTP 'Accept' Header -&gt; Content negotation through header http://xxx/user/123?v=1 -&gt; for perma-links/hyperlinks </code></pre> <p>One could also argue that such version content-negotiation could be part of the URI inside the path, but I find it counter-intuitive, because you could end-up with different URIs for the same resource and have to maintain redirects at some point.</p> <p>To sum-up: In REST URIs there is no api-versioning, only versioning of the resource's representation. Representation version-info belongs to content-negotiation (as queryParam or HTTP 'Accept').</p> <p>What do you think? In which things would you disagree/agree?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USmanuel aldana
    plurals
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTDuplicate
    3. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POREST api versioning (only version the representation, not the resource itself)
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POREST api versioning (only version the representation, not the resource itself)
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POREST api versioning (only version the representation, not the resource itself)
      1. USJacques René Mesrine
      1. VTFavorite
    1. COjust one little thing to add. the only showstopper to me and to use the ...v1/ style is, when you haven't got the load-balancing under control and can't define directions to the app-servers on HTTP header basis on the frontmachines (-> content-negotiation is part of the HTTP-header). Often the standard is to use the URL path. and in the web-frameworks I can think of it is difficult to define the request-mapping endpoints inside controller on HTTP-header basis instead of the path.
      singulars
      1. POREST api versioning (only version the representation, not the resource itself)
      1. USmanuel aldana
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload