<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>JSON:API on Coderrob</title><link>https://coderrob.com/tags/jsonapi/</link><description>Recent content in JSON:API on Coderrob</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Mon, 01 May 2023 18:00:00 -0600</lastBuildDate><atom:link href="https://coderrob.com/tags/jsonapi/index.xml" rel="self" type="application/rss+xml"/><item><title>Building Better REST APIs: A Hybrid Approach with JSend and JSON:API Guidelines</title><link>https://coderrob.com/posts/building-better-rest-apis/</link><pubDate>Mon, 01 May 2023 18:00:00 -0600</pubDate><guid>https://coderrob.com/posts/building-better-rest-apis/</guid><description>&lt;p&gt;This hybrid API design guide combines elements from both &lt;a href="https://github.com/omniti-labs/jsend"&gt;JSend&lt;/a&gt; and &lt;a href="https://jsonapi.org/"&gt;JSON:API&lt;/a&gt; to create a powerful and user-friendly approach for developing REST APIs. By adopting the best practices from both, this guide offers a consistent and maintainable API design.&lt;/p&gt;
&lt;h2 id="versioning"&gt;Versioning&lt;/h2&gt;
&lt;p&gt;API versioning can be achieved using a variety of methods such as URI-based route prefix, version in the header of the request, or as a query string value.&lt;/p&gt;
&lt;p&gt;The most common approach is using a URI-based route prefix for RESTful routes to define versions. This approach requires including the API version identifier as a part of the URL path, preferably as the first segment. For example, the API endpoint URL could look like:&lt;/p&gt;</description></item><item><title>Decoupling UI Copy From API Error Contracts</title><link>https://coderrob.com/posts/decoupling-ui-messaging-from-backend-error-codes-in-web-applications/</link><pubDate>Wed, 01 Mar 2023 18:00:00 -0600</pubDate><guid>https://coderrob.com/posts/decoupling-ui-messaging-from-backend-error-codes-in-web-applications/</guid><description>&lt;p&gt;Users need human-readable error messages. Software needs stable, machine-readable error identifiers.&lt;/p&gt;
&lt;p&gt;Neither should have to parse the other.&lt;/p&gt;
&lt;p&gt;That is the boundary I want when building error handling for a web application. The backend should explain &lt;strong&gt;what failed&lt;/strong&gt; in a predictable structure. The presentation layer should decide &lt;strong&gt;how that failure is presented&lt;/strong&gt; to the person trying to finish a task.&lt;/p&gt;
&lt;p&gt;In a smaller application, that presentation layer may be the browser. In an enterprise application, it may include a backend for frontend (BFF), a shared message catalog, or a localization service. The deployment diagram can change without changing the boundary.&lt;/p&gt;</description></item></channel></rss>