HATEOAS設計のサーバー側（応答で状態URLを返す）を理解していると合理的に確信していますが、これらを受け入れるようにクライアントを設計する方法について少し混乱しています。
たとえば、//somehost.com/resource/1のリソースにアクセスします。これにより、リソースデータとリンクが提供されます。//somehost.com/resourceへのPOSTが返され、「新しい」アクションを示していると想定します。これで、そのURLにデータを投稿すると、新しいリソースが作成され、応答が提供されることがわかりましたが、そのデータを投稿するフォームはどこにありますか？//somehost.com/resource/1/newが/resourceにPOSTするフォームを提供する実装を見てきましたが、そのURL自体に動詞が含まれており、RESTに違反しているようです。
私の混乱は、RESTfulAPIとそれを使用するクライアントを同じアプリケーション内に実装していることにあると思います。
この種のことについて、ある種のベストプラクティスはありますか？
//somehost.com/resource/1/newが/resourceにPOSTするフォームを提供する実装を見てきましたが、そのURL自体に動詞が含まれており、RESTに違反しているようです。
これは正しくありません。動詞を含むURIは、それ自体、REST制約に違反しません。これが違反になるのは、そのURIがアクションを表す場合のみです。URLに対してGETリクエストを実行し、意味のあるリソース（「新しいリソースの作成」フォームなど）を受け取ることができる場合、それは完全にRESTfulであり、良い習慣です。
私自身のAPIは、あなたが説明し/{collection}/newたとおりです。フォームを返します。/newは架空の略記であり/new-resource-creation-form、名詞を表し、GETリクエストのみをサポートします（HEAD、OPTIONS、およびTRACEは耐えられません）。
HATEOASが禁止しているのは、新しいリソースを作成するに/newは、コレクションの名前に追加する必要があることをユーザーエージェントが知っている必要があることです。
基本的に、APIを（X）HTMLとして実装し、ブラウザーでそれをサーフィンしてすべてのアクションを実行できる場合（HTMLとブラウザーがHTTPに追いつくまで、非POSTフォームの送信にはAJAXが必要になる場合があります）、 RESTのハイパーメディア制約。
コメントから昇格した編集：
応答が事前知識の必要性を否定する限り、それはハイパーメディアの制約に準拠します。クライアントがHTMLを理解していると主張し、クライアントがページを正しくレンダリングできるようにするために必要な外部スタイルシートまたはJavaScript（ホストされている場所に関係なく）へのリンクを含む応答を返送する場合は、次のように言うのが妥当です。制約が満たされていること。クライアントは、サポートすると主張するすべてのメディアタイプを処理する方法を知っている必要があります。通常の人間のWebブラウザーは、1つのHTTPサービス（Webサイト）に関する帯域外の知識がないクライアントの完璧な例です。
明確に言うと、Webサイトは一種のHTTPサービスです。Webブラウザーは、異なるWebサイトを異なる方法で処理しません。Amazonで商品を検索するには、Amazonサービスエンドポイントをにロードし、http://amazon.com/リンクをたどるか、その回答に記載されているフォームに記入します。eBayで商品を検索するには、eBayサービスエンドポイントをにロードhttp://ebay.com/して同じ操作を行います。ブラウザは、eBayを検索するためにこれ
を行う必要があることを事前に知りませんが、Amazonを検索するためにそれを行う必要があります。ブラウザは無知です。他のHTTPサービスのクライアントも無知である必要があります。
はい、リソース作成用のフォームを返すURIを提供できます。おそらく、このフォームは、新しいリソースを構築するために必要な要素の動的な検出に使用できます（ただし、マシン間環境で実際にどれだけ実用的であるかを判断する必要があります）。
どういうわけかAPIにブラウザでサーフィンできる正確な同等物があるという要件がない限り、メディアタイプのドキュメントには、必要な要素が記載されています。
メディアタイプとリソースに許可されているHTTP動詞のドキュメントは、RESTfulの原則に反するものではないことに注意してください。例については、SunCloudAPIをご覧ください。
確かに、あなたの例によれば、POSTは
//somehost.com/resource
新しいリソースを作成することは、最初にフォームを返すよりも標準的です
//somehost.com/resource/1/new
そして、投稿します
//somehost.com/resource
とりあえず。