{"_id":"572a2d3854312934004c74b5","parentDoc":null,"project":"5723ead0fda3c70e005b88e5","version":{"_id":"5723eaebeae5090e00ee61f1","__v":3,"project":"5723ead0fda3c70e005b88e5","createdAt":"2016-04-29T23:14:51.190Z","releaseDate":"2016-04-29T23:14:51.190Z","categories":["5723eaebeae5090e00ee61f2","5723f854110e570e00486c7a","572a28f6d10a200e00b1cb14"],"is_deprecated":false,"is_hidden":false,"is_beta":true,"is_stable":true,"codename":"","version_clean":"0.1.0","version":"0.1"},"__v":8,"category":{"_id":"572a28f6d10a200e00b1cb14","__v":0,"version":"5723eaebeae5090e00ee61f1","project":"5723ead0fda3c70e005b88e5","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-05-04T16:53:10.034Z","from_sync":false,"order":1,"slug":"concepts","title":"Concepts"},"user":"5723ea8efda3c70e005b88e3","updates":["57899c686a16260e006e7cc9"],"next":{"pages":[],"description":""},"createdAt":"2016-05-04T17:11:20.779Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":4,"body":"[block:callout]\n{\n  \"type\": \"success\",\n  \"title\": \"Key takeaways\",\n  \"body\": \"* Lever URLs provide a standard addressing scheme for methods across services and environments.\\n* They allow inter-service communication, regardless of the Lever hosting provider.\"\n}\n[/block]\nLever has a builtin addressing scheme for the methods within each service. Lever URLs are used throughout the Lever APIs for specifying the invokation target for [Lever RPCs](doc:rpc).\n\nHaving a standardized way of addressing Lever methods across environments and services allows for the methods to be available universally, in such a way that they can be routed appropriately across providers, over the internet.\n\nAs you can see below, Lever URLs can be either **absolute** or **relative**.\n\n# Absolute URLs\n\nAbsolute URLs are meant for invokation of methods across two different Lever environments (or from outside Lever altogether).\n\n```\nlever://<environment>/<service>[/<resource>]/<method>\n```\n\nFor example:\n\n```\nlever://myapp.example.com/someAmazingService/updateBooking\n```\n\nWhen using the [HTTP API](doc:http-api), the URLs are the same except for the scheme, which becomes `http` or `https`. For example:\n\n```\nhttps://myapp.example.com/someAmazingService/updateBooking\n```\n\n# Relative URLs\n\nRelative URLs omit the scheme and the environment. They are meant to specify an invokation within the same environment (or in some cases, to an environment that is inferred from the context).\n\nThe use of relative URLs is recommended for communication between services belonging to the same environment. This allows for the services to be easily portable to different environments (eg moving the services from a development environment to production), regardless of the actual name of the environment.\n\n```\n/<service>[/<resource>]/<method>\n```\n\nFor example:\n\n```\n/someAmazingService/updateBooking\n```\n\nRelative Lever URLs do not have an equivalent for the HTTP API.","excerpt":"This page describes a universal addressing scheme for Lever services and their methods","slug":"lever-urls","type":"basic","title":"Lever URLs"}

Lever URLs

This page describes a universal addressing scheme for Lever services and their methods

[block:callout] { "type": "success", "title": "Key takeaways", "body": "* Lever URLs provide a standard addressing scheme for methods across services and environments.\n* They allow inter-service communication, regardless of the Lever hosting provider." } [/block] Lever has a builtin addressing scheme for the methods within each service. Lever URLs are used throughout the Lever APIs for specifying the invokation target for [Lever RPCs](doc:rpc). Having a standardized way of addressing Lever methods across environments and services allows for the methods to be available universally, in such a way that they can be routed appropriately across providers, over the internet. As you can see below, Lever URLs can be either **absolute** or **relative**. # Absolute URLs Absolute URLs are meant for invokation of methods across two different Lever environments (or from outside Lever altogether). ``` lever://<environment>/<service>[/<resource>]/<method> ``` For example: ``` lever://myapp.example.com/someAmazingService/updateBooking ``` When using the [HTTP API](doc:http-api), the URLs are the same except for the scheme, which becomes `http` or `https`. For example: ``` https://myapp.example.com/someAmazingService/updateBooking ``` # Relative URLs Relative URLs omit the scheme and the environment. They are meant to specify an invokation within the same environment (or in some cases, to an environment that is inferred from the context). The use of relative URLs is recommended for communication between services belonging to the same environment. This allows for the services to be easily portable to different environments (eg moving the services from a development environment to production), regardless of the actual name of the environment. ``` /<service>[/<resource>]/<method> ``` For example: ``` /someAmazingService/updateBooking ``` Relative Lever URLs do not have an equivalent for the HTTP API.