Docs Developer Site
Enonic XP
arrow-down
    1. Overview
    2. Core concepts
    3. Using docs
    4. Intro Videos
    5. Tutorials
    1. Intro
    2. GraphQL API
    3. Media API
    4. Extending the API
    5. Component API
    1. Content Studio
      1. Branches
    3. Layers
      1. Lifecycle
      2. Media
      3. Attachments
      4. X-data
        1. Page templates
        2. Fragments
      6. Variants
      7. Permissions
      8. Versions
    5. Sites
      1. Visual editor
    7. Publishing
    1. Introduction
      1. Controllers
      2. Globals
      3. Events
      4. HTTP Request
      5. HTTP Response
      6. Error handler
      7. Filters
      8. Templating
      9. Localization
      10. Websocket
      11. Tasks
      12. Main controller
      13. Java bridge
      1. Admin Lib
      2. Application Lib
      3. Auditlog Lib
      4. Authentication Lib
      5. Cluster Lib
      6. Common Lib
      7. Content Lib
      8. Context Lib
      9. Event Lib
      10. Export Lib
      11. Grid Lib
      12. I18N Lib
      13. IO Lib
      14. Mail Lib
      15. Node Lib
      16. Portal Lib
      17. Project Lib
      18. Repo Lib
      19. Scheduler Lib
      20. Schema Lib
      21. Tasks Lib
      22. Value Lib
      23. VHost Lib
      24. Websocket Lib
    4. Other Libraries
      1. CLI
      2. Sandboxes
      3. Code
      4. Building
      5. Configuration
      6. TypeScript
    6. Building APIs
      1. Mappings
      2. Components
      3. Processors
      4. Contributions
    8. Building Webapps
      1. ID providers
      2. Admin Apps
      3. Admin Widgets
    1. Architecture
      1. TODO
      1. Navigating
      2. Users
      3. Applications
      4. Data management
      5. System info
      6. Audit Logs
      7. Task management
      1. Portal
      2. IDprovider
      3. Management
      4. Statistics
      1. Nodes and repos
      2. Properties
      3. Indexing
      4. Branches
      5. Editors
      1. DSL Queries
      2. NoQL Queries
      3. Filters
      4. Aggregations
      5. Highlighting
      1. ID providers
      2. System ID provider
      3. Users and groups
      4. Roles
      1. Strategies
      2. Distributions
      3. Docker
      4. Kubernetes
      5. Systemd
      6. Vhosts
      7. Configuration
      8. Backup & restore
      9. Clustering
      10. Observability
      1. Notes
      2. Upgrade
      3. Upgrading Apps
        1. Asset service
        2. HTTP service
        3. Image service
    1. Best practice
        1. AttachmentUploader
        2. Checkbox
        3. Combobox
        4. ContentSelector
        5. ContentTypeFilter
        6. CustomSelector
        7. Date
        8. DateTime
        9. Double
        10. GeoPoint
        11. HtmlArea
        12. ImageSelector
        13. Long
        14. MediaSelector
        15. Radiobutton
        16. Tag
        17. TextArea
        18. TextLine
        19. Time
        1. Field set
        2. Item set
        3. Option set
      3. Mixins
      4. Localization
      5. Styles
    3. Content Types
    4. X-data
    5. Macros
      1. Pages
      2. Regions
      3. Part component
      4. Layout component
      5. Text component
      6. Component Filtering
      7. Component Indexing
    1. Marketplace
    2. Market guidelines
Developer Docs Xp Next Runtime Engines Http Service

HTTP Service

Contents

HTTP Service is deprecated and will be removed in future releases.

Universal API is designed to substitute HTTP Service.

It is possible to control its availability via legacy.httpService.enabled parameter in com.enonic.xp.portal.cfg

HTTP Service enable mouting of http controllers safely made available within an application (or site’s) url space, without the use of routers. Due to the URL-pattern created, an http service will never conflict with other application url patterns. Services are in particular useful when used in the Site engine or webapps where URLs are not predictable.

Controller

To create a service, place an http controller file in the src/main/resources/services/ structure of your project. Each controller needs to be placed in a folder matching it’s name i.e.: src/main/resources/services/myservice/myservice.js

Example service controller

src/main/resources/services/<service-name>/<service-name>.js
exports.get = function(req) {
  return {
    body: {
      time: new Date()
    },
    contentType: 'application/json'
  };

};

Endpoint

Services use the following mount pattern: **/_/service/<appname>/<servicename>. This means that a service can be invoked in multiple locations, i.e. domain.com/_/service/.. or domain.com/some/path/_/service/... The context the service is mounted on can also be used by the controller as context.

As an example the service 'profileimage' will only work in context of a profile’s url. I.e. domain.com/profile/user1/_/service/myapp/profileimage will service an image, but invoked elsewhere it will not work.

Descriptor

By default, services may by used by any client or user. At times, it makes sense to restrict access to the service based on user roles. This can be done without custom coding.

Sample descriptor limiting access to the service:

src/main/resouces/services/<service-name>/<service-name>.xml
<service>
  <allow>
    <principal>role:system.admin</principal>
    <principal>role:myapp.myrole</principal>
  </allow>
</service>

serviceUrl()

To safely generate a service URL, use the serviceUrl() function that is part of the Portal Library.

When invoked, the function will generate a contextual service url based on the context of the current controller.

Contents

Contents

AI-powered search

Juke AI